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I. This Declaration establishes invention prior to April 23, 2003. 

II. This Declaration is being made by Allan Thomson and Sudhir Srinivas, i.e., the named 
inventors of the above-identified patent application. 

III. Conception: Prior to April 23, 2003, we conceived the inventions currently presented in 
independent claim 1 of the above-identified patent application. Claim 1 is attached 
hereto as Exhibit A. Claim 1 is exemplary of an embodiment of the inventions. Exhibit 
B includes a listing of files related to a product that is representative of the embodiment 
claimed in the exemplary independent claim 1. Exhibit B is intended to show 
conception prior to April 23, 2003. Exhibit B includes documentations that were 
created prior to April 23, 2003. The dates of each file have been redacted. Exhibit B 
includes the following documents: 

Bl: NMS Release 1.0 Functional Specification 
B2: User Management Screen Shots 
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B3: Trapeze Networks JumpPad Screen Shots 

B4: NMS-Schedule 

Exhibit B correlates to the exemplary independent claim 1. These correlations 
are for the purpose of example only, and not intended to limit the scope of the claims. 
TABLE 1 provides a rough correlation between Exhibit B and, for example, 
independent claim 1: 
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TABLE 1 



EXHIBIT B (Examples only) 


CLAIM 1 


Bl) 

• 


Functional Specification (pg. 6) 

o The Network Management Solution ("NMS") 
provides a solution to configuration/provisioning 
management, performance management, fault 
management, client management associated with 
wireless networks. 


(ai A method of olanninp 

Id I Xm. UIvIUVU UI uaHuuAug 

a wireless local area 
network, comprising: 


• 


Planning Network (pg. 7) 

o The user defines a network plan. The user is able to 
operate in either a "logical view" or a "topological 
view", (pg. 7, 1. Plan Network). 

o Planning involves creating new network plans or 
working with existing ones (pg. 30, 3.1 Network 
riansj. 




• 


Deploying Network (pg. 7) 

o The user physically installs devices such as APs. (pg. 
7) 




B2) 

• 


Management software screen shots. 




B3) 

• 


Trapeze Networks JumpPad Screen Shots 
o Trapeze Networks JumpPad shows screen shots 
captured from the working prototype. 




B4) 

• 


NMS-Schedule 

o The timeline shows the original project schedule 
from implementation to network performance 
updates 
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Bl) 

• Topological view (pgs. 11-12, 1.2.2.2 Topological View) 
o A topological view of the network shows topological 

objects like sites & buildings. The topological view 
displays all elements contained in the topological 
element. 

o In defining topological objects (pg. 31, 3.1.2.), the 
user selects, places, configures site, building, floor or 
walls. 

• Floor/Building/Site Level Performance (pg. 80) 
o The user selects a floor, building or site. 

B3) 

• Trapeze Networks JumpPad Screen Shots 

o Trapeze Networks JumpPad shows screen shots 
captured from the working prototype. 

B4) 

• NMS-Schedule 

The timeline shows the original project schedule from 
implementation to network performance updates. 


(b) receiving floor plan 
data about a site for the 
wireless local area 
network; 


Bl) 

• Selecting a topology object or pre-defined coverage area 
(pg.37) 

o In order to validate the coverage, the user must 
select a coverage area. This could be an existing 
topology object or could be a coverage area. (pg. 37) 

• Verification (or validation) of the network occurs at 
different phases. 

o Verification, for instance, of network configuration 
data occurs against the entire plan. (pgs. 53-56). 

B3) 

• Trapeze Networks JumpPad Screen Shots 

o Trapeze Networks JumpPad shows screen shots 
captured from the working prototype. 

B4) 

• NMS-Schedule 

The timeline shows the original project schedule from 
implementation to network performance updates. 


(c) receiving coverage 
data about the site for the 
wireless local area 
network; 
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B3) 

• Trapeze Networks JumpPad Screen Shots 

o Trapeze Networks JumpPad shows screen shots 
captured from the working prototype. 

B4) 

• NMS-Schedule 

The timeline shows the original project schedule from 
implementation to network performance updates. 


(d) receiving capacity 
data about the site for the 
wireless local area 
network; and 


Bl) 

• Menu Bar (pgs. 14-19) 

o The File/Edit/View menu provides the user with a 
variety of file based functions. 

• Verification of Network Configuration Data (pgs. 56-59) 
o The user changes the configuration and the changes 

will be verified before deployment. 

• Changes of Network Configurations (pg. 60) 

o The user can view or modify the configurations of the 
devices, VLAN or plan at any time. (pg. 60). 

• Performance Management (pgs. 75-81) 

o All performance parameters are accessible from the 
configuration views of the network, (pg. 75). 

B3) 

• Trapeze Networks JumpPad Screen Shots 

o Trapeze Networks JumpPad shows screen shots 
captured from the working prototype. 

B4) 

• NMS-Schedule 

The timeline shows the original project schedule from 
implementation to network performance updates. 

• 


(e) based at least on the 
floor plan data, the 
coverage data, and the 
capacity data, 
determining quantity, 
placement, and 
configuration of a 
plurality of access points 
of the wireless local area 
network. 
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IV. Diligence: We diligently constructively reduced the invention to practice on September 
17, 2003. Attached, with dates redacted, as Exhibits CI through C4 (collectively 
"Exhibit C") are exemplary documents produced between April 23, 2003 and 
constructive reduction to practice. It should be noted that Exhibit CI and B4 are the 
same. The date associated with this document is a range that extends from before April 
23, 2003, making it suitable for showing conception, and to after April 23, 2003, making 
it suitable for showing diligence. These documents are in chronological order, and have 
redacted dates which occurred at irregular intervals but without interruption extending 
from our conception of the invention to our constructive reduction to practice of the 
invention. Exhibit C includes the following documents: 

CI: NMS-Schedule 

C2: NMS 1.0 Software Design Specification 

C3: Ringmaster Release 1.1 Functional Specification 

C4: Ringmaster 2.0 Functional Specification 

Exhibit C correlates to the exemplary independent claim 1. These correlations 
are for the purpose of example only, and not intended to limit the scope of the claims* 
TABLE 2 provides a rough correlation between Exhibit C and, for example, 
independent claim 1: 
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TABLE 2 



EXHIBIT C (Examples only) 


CLAIM 1 


CI) 

• NMS-Schedule 

The timeline shows the original project schedule from 
implementation to network performance updates. 

C2) 

• RF Planning Tool (pg. 4) 

o The primary goals of RF Planning Tool include 
creating a coverage area, designing wireless 
network, defining obstacles in floor, assigning 
channels to different Access Points, (pg. 4). 

o Network design can be launched from the floor 
wizard, (pg. 10). 

o Network planner would perform defining a floor, 
obstacles, a coverage area or specifying certain 
constraints or deploying changes, (pgs 4-6). 

• RF Interference is a big problem in WLAN. The 
presence of RF obstacles within a floor can be seen on 
the actual coverage devices, (pg. 23). 

C3) 

• Planning Tool 

o New implementation of planning tool will be able to 
handle the following coverage areas: concave shaped 
coverage areas and shared coverage areas, (pgs. 18- 
19). 

C4) 

• RF Planning 

o Ringmaster RF Planning requires the user to select 
the appropriate chassis type they want to deploy in 
their network, (pg. 13). 


(a) A method of planning 
a wireless local area 
network, comprising: 
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CI) 



• NMS-Schedule 

The timeline shows the original project schedule from 
implementation to network performance updates. 



C2) 



• Floor Definition 

o A floor wizard controls the definition of floor. A 
wizard defines various factors such as partitions and 
floor attributes, (pgs. 7-9). 



(b) receiving floor plan 
data about a site for the 
wireless local area 
network; 



• Information Model 

o Information Model displays floor information such 
as background image, ceiling attenuation factor, 
obstacles, (pgs. 13-14). 

• Obstacles 

o The user can define obstacles and assign attributes 
such as attenuation factor, (pgs. 13-14). 

o The user will have to manipulate the floor plan. (pg. 
38). 

C3) 

• RF Obstacles 

o The attenuation factor of a RF obstacle is same in 
802.11b and 802.11g. (pg.ll). 



C4) 



• Channel Assignment 

o When channel assignment is performed for the 
entire floor, all 801.11b and 801.11g radios will be 
considered to reduce co-channel interference, (pg. 
12). 

• Floor View 

o A new icon which allows viewing the RF coverage 
will be added, (pg. 15). 

o Network topology verification is implemented with 
the introduction of 802.11g. (pg. 16). 

• Planning Tool 

o New implementation of planning tool will be able to 
handle the following coverage areas: concave shaped 
coverage areas and shared coverage areas, (pgs. 18- 
19)- 
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Network Topology Verification 
o Network topology verification is an important 
feature in Ringmaster, (pg. 13). 
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CI) 



C2) 



NMS-Schedule 

The timeline shows the original project schedule from 
implementation to network performance updates. 



Coverage Area Definition 
o This can be performed using In Floor Layout 
featured in the tool bar. (pg. 10). 

o Network design shows the list of coverage areas in 
the floor, (pg. 11). 

o Coverage area is a portion of the floor where the 
user desires certain WLAN connectivity, (pg. 14). 



(c) receiving coverage 
data about the site for the 
wireless local area 
network; 



o A coverage area has attributes such as user-specified 
area, average number of users, (pg. 14). 

• In network design, a set of constraints are specified and 
the list of coverage areas in the floor are selected for 
computation, (pgs. 10-11). 

• Information model includes coverage area data. (pg. 
14) 

o Coverage area is a portion of the floor where the 
user desires certain WLAN connectivity , (pg. 14). 

• Furthermore, in designing RF Network, the user must 
specify one coverage area or a set of coverage areas at a 
time. (pg. 16). 



C3) 

• There is a design constraint that the user is allowed to 
select. This constraint will become an attribute on 
coverage area. (pg. 8). 

• The user can choose 802.11g only or 802.11a and 
802.1 Ig in creating a coverage area. (pg. 10). 

o Coverage area will have an additional attribute to 
allow/disallow 802.11b clients, (pg. 10). 
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RF Coverage 

o A user must specify if contours are needed. If a 
coverage is selected, it will draw RF coverage for the 
technology of the coverage area. (pg. 12). 

o Wherever the coverage area is shown, the menu 
shows "Coverage Area", (pg. 14). 
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CI) 

• NMS-Schedule 

The timeline shows the original project schedule from 
implementation to network performance updates. 

C3) 

• Capacity based computation 

o It becomes critical in MP count computation that 
802.1 lg radio can accept 802.11b clients, (pg. 11). 


(d) receiving capacity 
data about the site for the 
wireless local area 
network; and 


CI) 

• NMS-Schedule 

The timeline shows the original project schedule from 
implementation to network performance updates. 

C2) 

• Design and Computation 

o The user selects the coverage areas for computation 
and upon finishing computation, the new Access 
Points will be shown, (pgs. 10-11). 

• Assigning Channels 

o A wizard will ask the seed AP and Channel to 
automatically assign channel numbers to the other 
APs. (pg. 12). 

• Design Constraints 

o The network planner provides certain constraints 
such as max. AP-DP distance, existing APs. (pgs. 14- 
15). 

• RF Network Design Computation 

o The user must specify the following pre-requisites: 
location of wiring closet, coverage area and so on. 
(pg. 16). 

• AP Computation 

o The crux of designing RF Network is to place APs 
for optimal coverage, (pg. 16). 

C4) 

• Deploying MP configurations 

o The user deploys the MP configuration in deploying 
MP configurations, (pg. 17). 


(e) based at least on the 
floor plan data, the 
coverage data, and the 
capacity data, 
determining quantity, 
placement, and 
configuration of a 
plurality of access points 
of the wireless local area 
network. 
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V. We hereby declare that all statements made herein of our own knowledge are true and 
that all statements made on information and belief are believed to be true; and further 
that these statements were made with the knowledge that willful false statements and 
the like so made are punishable by fine or imprisonment, or both, (18 U.S.C §1001) and 
that such willful false statements may jeopardize the validity of this application or any 
patent issued thereon. 
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Claim 1 



1. A method of planning a wireless local area network, comprising: 

receiving floor plan data about a site for the wireless local area network; 
receiving coverage data about the site for the wireless local area network; 
receiving capacity data about the site for the wireless local area network; and 
based at least on the floor plan data, the coverage data, and the capacity data, 

determining quantity, placement, and configuration of a plurality of access points of the 

wireless local area network. 
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1 INTRODUCTION 



1.1 GOALS AND SCOPE 

The goal of this document is provide a functional specification of the Trapeze Networks network 
management product. It is not intended to be a software design specification or define future release 
requirements or functionality. It is strictly focused on the release 1 .0 product capabilities. 

NOTE: The internal product name is "JumpPad". We use "JumpPad" throughout this document and this 
name will be replaced by the eventual product name in all distributed software and manuals. 

1.2 OVERVIEW 

The primary focus of the network management solution in the 1.0 timeframe is to provide a solution to 
the following functional areas associated with managing Trapeze Wireless networks: 

• Configuration/Provisioning Management 

o It is really important that we provide tools to enable a network manager to easily 
plan and provision networks built from our equipment. 

o The tools must encompass configuration for new networks as well as existing 
deployed networks and manage both images and configurations in an integrated way. 

• Performance Management 

o For our networks it will be critical that we provide tools to understand how the 
network is performing for both the wired and wireless parts. 

• Fault Management 

o Faults in the network, particularly wireless, will be common place and it is necessary 
we provide insightful ways of showing and highlighting issues that are occurring in 
live networks. 

• Client Management 

o As part of the solution we will provide mechanisms to find clients in the network and 
do basic performance/fault management for those clients. 

Other key goals for this product are: 

• Easily installed and running quickly. 

o No complicated installation or pre-installation requirements. The product should be 
downloadable from the web and running within minutes of installation. 

• Demo friendly. 

o For our company to be successful, it is CRITICAL that the network management 
product gives a great demo to our customers and allows us to show the full 
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capabilities of the network products. It should clearly highlight the company/product 
differentiators. 

• Integrates with existing customer tools 

o Most enterprise networks consist of OEM equipment and therefore other tools will 
be required by a network manager if they are managing such environments. We have 
to co-exist with such tools gracefully and not assume or require that the customer is 
running only our solution. 

Our tool will target fitting into a network manager's workflow rather than forcing the network manager 
to change how they do their job. Most network manager's follow the common steps described below. These 
steps are not a strict sequence, as depicted by Figure 1 : 

1 . Plan Network 

• The user defines a network plan. The goal is to easily define devices (DPs, APs, etc.) and 
topological elements like sites, buildings, floors, etc and mappings between the two. The user 
is able to operate in either a "logical view" where the network plan is presented as a list of 
devices and connections, or a "topological view" where the network plan also contains 
buildings, floors, etc (and the mappings between devices and the topology.) A logical view 
shows a containment view with DPs, APs, and links, regardless of where they are located. A 
topological view allows the user to see which devices are contained in, for example, a floor 
regardless of their device associations. It is possible that the user does not define any 
topological elements in which case only the logical view is available. 

2. Deploy Network 

• The user (or someone) physically installs the devices. Next, the user will select a set of 
network elements in a network plan and change them to a managed state and deploy a 
configuration to them. This will cause the application to initiate communication with the 
network elements. The user must be able to do this in a piecemeal fashion (mainly to allow a 
steady growth of networks.) 

3 . Operate Network 

• In this mode the user performs "normal" day-to-day operation of the system. Also, the user 
can easily start augmenting and growing the network (which puts them back into the plan- 
deploy-verify steps.) 

4. Verify Network 

• The user runs a set verification tests on the parts of or the entire network configuration. 
Verification could really occur during planning, deployment or operation. The user will verify 
network configuration during planning. The user can also run validation algorithms on a 
planned network to see problems in the network coverage. Once the network is deployed, the 
user will verify the installation against the planned (for example, checking if a DP reports a 
planned number of APs.) The user will also need to easily detect problems in coverage and 
use. The user is also able to verify the configuration of a device. Any of these functions can 
be invoked when the network is in operation. 
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Figure 1 : Work Flow State Diagram 




1 .2. 1 APPLICATION FUNDAMENTALS 



1.2.1.1 MANAGED VS UNMANAGED DEVICES 

The application will provide the user with the ability to manage or unmanage devices. For managed 
devices, the application will communicate the changes to the device when the user decides to "deploy" the 
changes. If changes are made to an unmanaged device, the changes are only applied to the local copy of the 
network configuration and no attempt will be made to communicate with the device on the network. This 
allows us to provide offline creation of network configurations before the network exists or has IP 
connectivity. 



7.2. 7. 2 OFFLINE CONFIGURATION CHANGES 

The application will provide an offline configuration workflow. That is, the user will make a set of 
changes to the network configuration within the application and those changes will be recorded in a change 
set. For a set of changes to be applied to the actual network, the user will invoke the "Deploy" option. If the 
user exits the application without deploying the changes or the changes were applied to devices not actually 
managed on the network yet, the changes will be stored offline and the next time the plan is opened those 
changes will be re-applied to the current view of the configuration. 



Performance and Fault functions will only be permitted on network configurations that are managed in 
the network. This means that if the user chooses to monitor the performance of a VLAN not yet deployed 
the application will inform the user that it is not possible to perform this function until the changes are 
deployed. Similarly, any fault functions provided by the application will only work if the device is 
managed and that function applies to a piece of the network configuration that exists on the device in the 
network. 
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7.2.7.3 VERSION1NG SUPPORT 

The product will support versioning of the DP/AP product capabilities. That is, it will support multiple 
versions of the images and their associated capabilities. A device capability can be a difference in 
configuration model (e.g. new features, extended limits.. .etc), performance management changes (e.g. 
additional parameters being added to the data returned for statistics) and fault management changes (e.g. 
additional parameters being added). As part of DP/AP configuration, an image version will be associated 
with each device. This version will define the capabilities the product will support from a configuration 
capability. For our product it is a requirement that the product supports multiple image versions in a single 
version of the JumpPad product. For 1 .0, this will not be a big issue, but with future rollouts of images it is 
critical that the product be easily adapted to handle the differences in device capabilities. 

L2AA GENERAL LOOK AND FEEL 



The application will use the default look and feel of the OS it is installed upon. For Windows XP/2000 
this will default to the Windows look and feel. For Solaris, this will default to the Motif look and feel. 




The application will consist of: 



• Main Menu Bar. This will provide the user the main navigation to the set of functions 
provided by the application. 
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• Tool Bar. This will provide shortcuts to the set of functions in the menu bar. 

• Organizer Panel. This will provide a tree hierarchy structure to the various views the user can 
navigate in. 

• Context Pane. This will provide the user with a variety of views for 
configuration/fault/performance of the network. 

• Task List. This will provide the user with a set of available functions for the current selection. 

• Context Popup Menu. A popup menu will be displayable for each object and will provide the 
set of related functions for the current selections. The product will support multi-select of 
objects and therefore this context menu will be based on the first selection rather than all. 

1 .2.2 ORGANIZER PANEL 

The Organizer Panel will allow the user to easily view the network from either a logical containment 
view or from a topological view. Ultimately, both views allow the user to see the DPs, APs and other 
elements of the network. By selecting an element on the panel, the user can: 

• Right-click on it to see a list of available operations. This will include a menu option to display a 
pop-up window with the configuration details of the selected element (this may not make sense for 
all objects, and will be context-sensitive.) 

• Double-click on it to focus the context panel to that object. 

7.2.2.7 LOGICAL VIEWS 

A logical view is a containment tree of devices. These do not show any topological elements, like sites, 
buildings and floors. Using the logical view the user can select a device. To show more information for the 
device the user can right-click and select a menu option to display its configuration. For example doing this 
on a port will show if it is connected to an AP, which VLAN it is part of, etc. 
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1.2.2.2 TOPOPLOGJCAL VIEW 

A topological view of the network shows topological objects like sites & buildings. One point to note: 
APs may be connected to DPs in a different location (e.g. a different floor or building.) Hence, the 
topological view displays all elements contained in the topological element. By expanding on a DP, a user 
will be able to see the APs that it is connected to regardless of their location. 
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1.2.23 VLAN VIEWS 

VLANs are seen in both logical and topological views, and can also be accessed using a separate 
VLAN view. 

Since VLANs can span top-level network & topological elements, they are shown directly under a plan 
in both logical and topological views. For any element, its VLAN associations can also be obtained by 
using a right-click menu option. 

The VLAN view shows only the VLANs under the plan - i.e. all other elements are filtered out. 
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L2.2.4 USING THE VIEWS 

For any network element, the user can select a menu option to either show the location, or show its 
logical associations. This allows the user to quickly navigate to the desired information. Also, if the user 
has selected a network element and then switches modes, the same element will become the focus of the 
new mode. Hence a user can select an AP in a topological view, and then switch to a logical view to see 
what DP it is connected to. 

If a user select an element in logical or topological view, and then switches to a VLAN view, all 
VLANs that the device is part of are highlighted in the VLAN tree. 



1 .2.3 CONTEXT VIEWS/EDITORS 

The Context Views/Editors provide various windows that show topology, allow the user to edit 
parameters for objects, show performance, show alarms. ..etc. 

1 .2.4 SELECTION OPTIONS PANEL 

The Selection Options Panel provides a quick way for the user to see the options available for the 
current selection. For example, if the user chooses a port, they can choose to edit parameters, graph 
performance, show alarms... etc. The selection options panel is just another toolbar with text and icons 
shown and is context based so that the options available for this object are only shown when that object is 
selected. This panel is closeable. 
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1.2.5 MENU BAR 

All the Menu items under the menus are context-sensitive. All of the menu items are enabled or 
disabled based on that what the current selected object is. For example, under the context of "Floor", the 
"Insert" menu item will only show up the "DPChassis", but not the "Port" submenu item. 



7.2.5.7 FILE MENU 

The File menu provides the user with a variety of file based functions such as creating new network 
plans, saving network plans, importing/exporting configuration/image files... etc. This following menu 
items are currently supported under File menu: 

• New Menu Item 

o This New menu item will enable the user to start a new network plan. It will prompt 
the user to enter a new network plan name it is selected. 

• Open Menu Item 

o Open Menu item provides the user to open an existing network plan, whether it is an 
active plan or undeployed network plan. 

• Save Menu item 

o This menu item provides the user to save the existing network plan. If it is first 

• Save As Menu Item 

o This menu item allows the user to save the network plan to a file on the local disk. 

• Print Menu Item 

o This menu item allows the user the print the existing network plan or map view. 

• Import Menu Item 

o This menu item will allow the user to import configuration files defined in CLI or 
XML format into the system. 

• Export Menu Item 

o This menu item will allow the user to export device configurations to either CLI or 
XML format files on the local hard disk. 

• Exit Menu Item 

o This menu item will exit the Trapeze JumpPad system. 
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1.2.5.2 EDIT MENU 

The edit menu provides the user with a variety of current options available for the currently selected 
object. The following menu items are provided: 

o Insert Menu Item 

Insert Menu Item provides the user the ability to add any allowed objects under the 
current context. For example, if the Floor object is currently selected, the Insert menu 
item will give the option of inserting DPChassis under the Floor. 

o Properties Menu Item 

This menu item allows the user to view or modify the configuration information of that 
selected object such as Chassis or port. 

o Cut Menu Item 

This menu item allows the user to delete an object based on the currently context. For 
example, delete a DP or AP from the network. 

o Copy Menu Item 

o This menu item provides the user the capability to do the object cloning. For 
example, clone the same AP configuration of a selected AP. 

o Paste Menu Item 

This menu item provides the user to paste the Copied objects to a different location or 
hierarchy. 

o Online/offline Menu Item 

This menu item provides an easy way to change the state of the Chassis to offline, or 
online. 
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1.2.5. 3 VIEW MENU 

The view menu provides the user with the ability to switch between different views and for the current 
view provides options to change that view. The following menu items are provided: 

o Map Menu Item 

Map Menu Item provides the map view of the existing network plan. This menu item is 
the same tab shown on the left-top of the Organizational Panel. 

o VLAN Menu Item 

VLAN Menu Item provides the logical view of the VLANs, DPs, and APs, and their 
connectivity. 

o RF Coverage Menu Item 

This option allows user to view the coverage of a Network plan; this may includes Building, 
Floor, VLAN, and DP saturation for each site within a Network Plan. 

o Images Menu Item 

Images View shows a list of DP and AP config files and images and provides a list of 
functions to manage the image file and provides download to the DPs. 

o Task List Menu Item 

This menu item provides the user a list of functions to toggle on and off the 
Configuration Task List on the right side of the Context view. 

o Toolbars Menu Item 

o This menu item provides an easy customization of the Tool Bars and the user can 
choose to select and deselect the short-cut of each menu on the tool bar. 
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1.2.5.4 CHANGES MENU 

The changes menu provides the user with the ability to save network changes, discard changes... etc. 
The following options are available in the JumpPad system: 

• Deploy Menu Item 

o This will allow the user to deploy the network plan to the network devices. 

• Revert Menu Item 

o This option allows the user to revert the changes back to the previous state of the 
configuration view before the user made any changes. 

• Review Menu Item 

o This menu item allows the user to review the changes that they have made in the 
current view. 

• Verify Menu Item 

o This option allows the user to verify the network plan for configuration errors. For 
example, the differences between the actual and planned configuration are identified. 

1.2.5.5 PERFORM A NCE MENU 

The Performance menu allows the user to retrieve and view the Performance and Statistics of the 
selected object, such as VLAN, Chassis, and port. All options are context sensitive and will show the 
performance information for a particular selected set of objects. If the user does not select a particular 
object the option will provide the user with a list of objects that the function may be performed on. 

• VLAN Menu Item 

o VLAN Menu Item provides the Graph and Chart Statistics for the VLAN. 

• Chassis Menu Item 

o Chassis Menu Item provides the Graph and Chart Statistics for a selected Chassis. 

• Port Menu Item 

o Port Menu Item provides the Graph and Chart statistics for a selected port. 
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7.2.5.(5 FA UL T MENU 

The Fault menu allows the user to retrieve and view Fault/Event log of the selected object, such as 
VLAN, Chassis, and port. The user should be able to select any object such as a DP, or a port, and launch 
the Fault Viewer for that particular object. All options are context sensitive and will show the fault 
information for a particular selected set of objects. If the user does not select a particular object the option 
will provide the user with a list of objects that the function may be performed on. 

• VLAN Menu Item 

o VLAN Menu Item provides the Fault/Event Viewer for the VLAN. 

• Chassis Menu Item 

o Chassis Menu Item provides the Fault/Event viewer for a selected Chassis. 

• Port Menu Item 

o Port Menu Item provides the Fault/Event Viewer for a selected port. 

7.2.5.7 REPORT MENU 

The Report menu allows the user to generate and export the report on the selected object, such as VLAN, 
Chassis, and port. The user should be able to select any object such as a DP, or a port, and allows the sub 
selection whether on Configuration, statistics, or event/fault report. 

• VLAN Menu Item 

o VLAN Menu Item generates the report for the VLAN. User needs to select a 
particular VLAN and launch the Fault menu. Under this menu 

• Chassis Menu Item 

o Chassis Menu Item provides the Fault/Event viewer for a selected Chassis. 

• Port Menu Item 

o Port Menu Item provides the Fault/Event Viewer for a selected port. 

Issue: More importantly the user wants to generate report not only on the physical configuration, 
but also Performance/Statistics. 
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1.2.5.8 TOOLS MENU 

The tools menu provides launch points for the tools we may integrate into the application. 

• Preferences Menu Item 

o This menu item provides the user to specify User preferences such as Font, Color, 
and organization of the window etc. 

• Security Menu Item 

o This menu item allows the user to manage security features, such as user-based 
authentication. 

• Launch Telnet Menu Item 

o This menu item provides a launch point for the telnet window against a selected set 
of devices. 

• Launch Web Browser Menu Item 

o This menu item allows the user to launch the web browser against a selected set of 
devices. 

7.2. 5. 9 WINDOW MENU 

The window menu provides the user with the ability to control the current windows in the MDI pane 

• Cascade Menu Item 

• Tile Horizontal Menu Item 

• Tile Vertical Menu Item 

• Arrange Menu Item 

• Close All Menu Item 

• Help Menu 

The help menu provides launch points into the online help system. In 1 .0 this is likely to be a 
PDF file. 

o About Menu Item 

♦ o Index/Search Menu Item 

This menu item provides the indexing and searching capability of the online 
Help file. 
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1.3 PLATFORM SUPPORT 

1 .3.1 OPERATING SYSTEMS 

The following operating systems will be supported in the first release. 

• Windows XP 

o Minimum requirements: 256MB RAM, 30MB free disk space, 1024x768 screen 
resolution, and 24-bit color. 

• Windows 2000 

o Minimum requirements: 256MB RAM, 30MB free disk space, 1024x768 screen 
resolution, 24-bit color 

• Solaris 

o Minimum requirements: 512MB RAM, 30MB free disk space, 1024x768 screen 
resolution, 24-bit color 

1.4 SCALING REQUIREMENTS 

The system will target the following size of networks: 

• 50 DPs 

• 1000 APs 

• 5000 Users 

This is by no means a theoretical maximum, but a single installation of JumpPad should handle this 
number of devices comfortably. 
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2 SETUP 

Before the user begins planning and operating a network some basic preliminary tasks must be 
performed. This section describes such tasks. 

2.1 INSTALLATION 

The product will have various installation options, all of which are supported by Install Anywhere (a 
commercial Java installation product): 

• From CDROM 

• From the Web (Web Start will be supported only in post 1 .0 release) 

All options will download a single installer executable that unpacks itself and then install the product. 
All installations will install a JVM as part of the installation. We will use Java 1.4 JRE from Sun for all 
supported platforms. The JRE will be installed as part of the installation and we will not require the user to 
have a JRE pre-installed. 

2.1.1 JUMPPAD INSTALLATION 

The JumpPad installer will consist of a single main self-installer that installs all required files for the 
JumpPad (including JVM). The JumpPad application will be installed under the following default 
directories under different platforms: 

On Windows (2000 and XP) platforms: 

\Program Files \ Trapeze Networks \JumpPad\ 
On Solaris platforms: 

/opt/trapezenetworks/JumpPad/ 
The installed directory structure under either install directory will be: 



\bin 


(with all the executables and startup scripts) 


\lib 


(with all the jar files) 


\db 


(with all the persistent data like dxf files, config xmls etc) 


\images 


(with all the images downloads) 


\help 


(online help files, probably HTML file format) 


\hpov 


(HP Openview integration files including installer) 


\jre 


(The JVM that is required for our product to run) 



We will provide a HP OV plug-in installer that can be invoked by the user manually after installation 
of the JumpPad. We will provide a check in the main installer that will see if HP OV is installed on the 
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machine and prompt the user if they want to run the HP OV plug-in installer after the main installer is 
complete. All files for the HP OV will be installed under our install directory and the plug-in installer will 
then install from there to the HP installation directories. 

2.1.2 JUMPPAD UNINSTALL 

JumpPadl.O will uninstall all the components including 3 rd party components if there are any. We will 
leave zero footprint on the machine if uninstall is successful. 

We will recommend in the 1.0 timeframe that all previous versions of the JumpPad (i.e. beta/test 
versions) be uninstalled before continuing to install the product. We will provide a check in the installer 
that test for previous installations (on Windows this will be a registry check, Solaris?). If the test finds a 
previous version the user will be able to continue but we will automatically move everything out of the way 
before continuing the installation. 

Subsequent releases (post 1 .0) will provide upgrade utilities for the installation and allow the user to 
install newer versions (patch/minor or major) on top of previous versions. Particularly patch and minor 
updates will just upgrade the current installation. Depending on the type of changes being released, this 
may require conversion of existing database files... etc to the newer release. 

2,2 MANAGEMENT PLATFORM INTEGRATIONS 

HP Openview will be the only supported network management platform supported in the 1.0 timeframe. 
The goal is minimal integration providing some basic launch points, custom graphics for our nodes in HP 
OV and enterprise MIB (i.e. traps) support. 

All platforms provide Basic L3 topology maps and are common in Enterprise environments. The 
installation of our product does not require these products to be in use. However, we will not duplicate L3 
topology. Topology of the DP/AP will be covered in a later section. 

2.2.1 HP OV LAUNCH POINTS 

The application will be launchable from the OVW Tools menu. The menu item will be called "Trapeze 
JumpPad". The user will not be required to select and particular devices to launch our application. Several 
scenarios exist: 

1. A Trapeze Networks network is already deployed and the user is invoking our 
application for the first time. 

a. Upon invocation we will ask the user if they want to import devices from the OV 
database into our application. If yes, the application will read ALL Trapeze devices 
from the OV database and show them in a logical view. Upon completion of reading 
the OV database we will prompt the user for a username/password to read the 
configurations from the devices on the network. 

2. The user has run the JumpPad before either from HP OV or manually invoked and has 
nothing selected in the OV view. 

a. In this case, we will start the application in a normal mode (i.e. prompt for new plan/ 
open existing plan... etc) 

3. The user has run the JumpPad before and has selected a particular device(s) in HP OV. 
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a. In this case, we will search our plan database for those devices and open the 
particular plan that the device is in. If multiple plans exist with the device, we will 
ask the user which one to open. 

Whenever we read information from the OV database we will gather a device's IP address and 
hostname as a minimum. More information maybe read as we find out more about what is in the database. 

2.2.2 HP OV REGISTRATION FILES 

To integrate with HP we must provide and install registration files that allow our application to be 
launchable from the HP OV menus. The registration file for our application will be called 
"trapezenetworks.ovw" and installed in the following locations 

On Windows: C:\Program Files\HP OpenView\WJMVegisrration\C 

On Unix : /etc/opt/O V/share/registration/C 

The contents of the file will be mostly as follows: 

Application "Trapeze JumpPad" 

{ 

Description { 

"Trapeze Networks JumpPad", 
"JumpPad for Trapeze" 

} 

DisplayString "Trapeze JumpPad"; 



Version "JumpPad 1 . 0 




Copyright { ____ 

"Copyright (c) JRISPTrapeze Networks Company", 
"All rights reserved" 

} 

Command "trpz JumpPad -shared" 

MenuBar <100> "Tools" _T 
{ 

<5> "Trapeze JumpPad" _M CONTEXT "AllContexts | | isIP" 
f . action "trapeze- JumpPad" ; 

} 

Action "trapeze- JumpPad" { 
MinSelected 0 ; 

MaxSelected 1 ; 

SelectionRule ( isSNMPSupported | | isSNMPProxied) ; 

NameField "IP Hostname", "IP Address", "Selection Name"; 

} 

} 

We will also provide enterprise MIB integration and this will require us to copy the necessary MIB 
files into the appropriate HP OV directory containing the MIBs. Details TBD. 
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We will also provide custom icons to show Trapeze Networks devices in the HP OV maps and this will 
require installation of symbol files... etc into HP OV directory structure. Details TBD. 



2.2.3 SYNCHRONIZING HP OV STATE 



Pre-conditions 


HP OV is accessible. JumpPad is installed and JumpPad plug-in to HP-OV is installed. 


Post-conditions 


JumpPad is configured to sync with HP OV. 


Main-Flow 


1 . User selects the Preferences menu option. The preferences dialog will have a HP 
OV integration panel with various choices. 

2. JumpPad will have the following option: 

a. Sync New Nodes. This option will switch on/off our application checking 
for new Trapeze nodes discovered in HP OV. This option only applies 
when the application is running already and HP OV discovers a new node 
and sends an event to us saying a new device is discovered. 

D. oyric iNt)ue oiaiub. inib option win swiilii on/oil oui application opening 
a connection to OV on startup. If on, our application will open a 
connection to the OV database and register interest in events associated 
with the Trapeze device status. OV provides callback mechanisms so that 
when events occur (status change) we can receive the event 
asynchronously. Upon receipt of a node status update from HP OV we 
will color our device nodes with the same color coding as shown in the 
HP OV map. 


Exceptions 




Alternate Flows 




Notes & Issues 


• The HP OV integration can be done at any time. 
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2.3 CONFIGURING USER-BASED AUTHENTICATION 

The JumpPad supports a user-based authentication policy that leverages the underlying platforms user 
management scheme. By default this policy is disabled. 

As part of the JumpPad, an administrative user is allowed to turn on the user based authentication and 
to define a set of users that can use the JumpPad on that system. 



2.3. 1 USER BASED AUTHENTICATION 



Pre-conditions 


JumpPad is installed 


Post-conditions 


The user-based authentication feature is turned on and a JumpPad user list is created 
for the system. 


Main-Flow 


1. The Administrator invokes the User Control function. A password may be 
required to access this function, based on prior settings (see below.) 

2. The Administrator enables user-based authentication. 

3. The administrator sets a password for subsequent management of user- 
authentication. 

4. The Administrator defines one or more system user names that are allowed to use 
the application. 

5. The User Control application encrypts the user names and stores them as Java 
system properties. 


Exceptions 


2a. The Administrator quits: 

3 . The application informs the administrator that no users are defined, and 
prompts them to either define a user or turn-off user based security. 


Alternate Flows 


2a. The Administrator disables user-based authentication: 

1 . No user authentication is performed in future runs of the application. 
3a. The Administrator does not set a password for managing user-based authentication: 

1 . No password check is done when the User Control function is invoked. 
4a. The Administrator deletes one or more system user names from the existing list. 

1 . The deleted user will not be able to subsequently run the application. 


Issues & Notes 





JumpPad will provide a menu option to access the user-based authentication security feature: 
• Menu Option: Tools -> Security 
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File Edit View Changes Performance Fault Tools Windows Help 




Security 





This feature can be protected by a password. By default there is no password. Only if a password has been 
previously set, the user will be prompted to enter it. 



Accessing this function requires a 
password: 



Enter Password: 



******** 



Enter Cancel 



If the password does not match, the user will be informed of this error and re-prompted for the password: 



Accessing this function requires a 
password: 

ERROR: Invalid Password 



Enter Password: 



******** 



Enter 



Cancel 



Next, the user is then presented with a single screen that allows the management of user-based 
authentication. Here, the user can: 



1) Turn the user-based authentication on or off. 

2) Turn the password protection of user-based authentication on or off. 

3) Set a password (if password protection is enabled.) 

4) Add or delete user names that can access the application. 
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User Authentication: 



Set Password: 



Password: 
Re-enter: 



UserN 



Add 



On O Off 
On O Off 



******** 



******** 



User List 



User 1 
User 2 
User 3 



UserN- 



(ALLAN: By definition, setting a password turns password security on, I don't 
believe having an additional toggle button to turn this on/off helps, it is redundant] 



2.4 APPLICATION STARTUP 



2.4. 1 STARTING JUMPPAD 



Pre-conditions 



JumpPad software is installed 



Post-conditions 



JumpPad is started 



Main-Flow 



1 . User can start JumpPad using any of the following options: 

• From command line: by typing in the application name 

• By double-clicking a desktop icon or selecting a desktop menu option. 

• By using a HP OV launch-point 

2. JumpPad checks security policy to see if user authentication is enabled. 

3. If user-based security is enabled: 

a. JumpPad retrieves security data 

b. JumpPad authenticates the user against a pre-defined list of allowed users 
as 
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4. JumpPad retrieves the user's preferences. If none exists, the JumpPad will just use 
the defaults built into the product. As soon as a preference is changed the JumpPad 
will save the complete set to the user's specific directory. 

5. JumpPad gives the user options to: 

a. Open an existing network plan. If the user had previously used the 
JumpPad the JumpPad will display a list of "recently opened" plans. 

b. Start a new network plan. 


Exceptions 




Alternate Flows 




Issues & Notes 





On starting up JumpPad, the user is prompted with a dialoge box, as follows: 




New Network Plan 
Enter Name 



Open Network Plan 
Select Network 



Continue 



Cancel 



BuildingA-Floorl 



Existing Plan List. 

BuildingA-Floorl 

BuildingB-Floor2 



This box is shown in front of the main application window. If the user hits cancel, the main window stays 
running, with only the MENU: File -> New and the MENU: File -> Open functions accessible. 



2.4.2 AUTHENTICATING USERS 



Pre-conditions 


An administrator has built a JumpPad user list with Use Case - Build User List 


Post-conditions 


User is authenticated and allowed to use the JumpPad. 


Main-Flow 


1. JumpPad application retrieves allowed user list (which is stored as Java system 
properties.) 

2. JumpPad application uses the Java authorization package to query the system 
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about the current user. 

3. If the current system user is on the allowed user list, the user is authenticated. 

4. If the current system user is NOT on the allowed user list, the authentication 
request is failed. 


Exceptions 


la. Empty user list 

1 . Authentication request is failed. 


Alternate Flows 




Issues 


a. Should authentication be done at a more granular level? E.g. for function groups? 

b. Are there user levels/privileges: read-only, change, etc. 



For valid users there is no password to enter, when they start JumpPad. If JumpPad detects an invalid user, 
it will inform the user as follows: 



ERROR: The user account (User 1) is not 
configured to use JumpPad. Please inform 
the JumpPad administrator or re-try with a 
different account. 



Ok 
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3 PLAN 



Planning involves creating new network plans or working with existing ones. A network plan is a collection 
of network device definitions, topological definitions, maps and background image files. 

The user has a number of different options for defining and importing data into a network plan. These are 
described in detail below: 



3.1 NETWORK PLANS 



3.1.1 STARTING A NEW NETWORK PLAN 



Pre-conditions 


JumpPad is installed 


Post-conditions 


User has created & saved a new network plan. 


Main-Flow 


1 . User starts JumpPad. 

2. JumpPad tool authenticates user with Use Case - Authenticate User 

3. JumpPad tool places the user into a blank network plan (sort of like being in 
Document 1 when you open Word.) 

4. User does any of the following (in any order) until the plan is complete or ready to 
be saved : 

• User defines topology objects - #Use Case - Define Topolosv Obiects 

• User defines & configures devices - #Use Case - Define & Configure 
Devices 

• User imports a .dxf file and defines topologv objects from it - #Use Case - 
Import .dxf File 

• 1 Iser imports an HP OV device list and defines devices from it - #Use Case - 
Import HP OV Device Discovery 

• User can import data from a device - #Jmport from Device. 

5. User saves the network plan. 

6. The JumpPad puts the plan into a persistent store or disk. 


Exceptions 




Alternate Flows 


3a. User opens an existing network plan. 

I . Proceed to Use Case - Work On A Saved Network Plan 


Issues & Notes 


• Not too sure about the Word model. It could be irritating to always start with a 
blank document - but this could of-course be a user configurable. Will users be 
constantly switching between a large set of models/files, or will they typically 
only use one. 

• Do we need to version the files? With a FS the user can simply rename. 
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3. 1 .2 DEFINING TOPOLOGY OBJECTS 



Pre-conditions 


User is working on a network plan and wants to define/modify the topological view of 
the plan. 


Post-conditions 


User has successfully defined/modified the network topology. 


Main-Flow 


1 . User selects any one of the following objects (from a menu or palette): 

a. Site 

b. Building 

c. Floor 

d. Walls 

2. User places object on the drawing area. 

3. User configures the attributes of each object: name, location (co-ordinates?), 
dimensions, any obstruction characteristics (e.g. a thick wall), etc. 

4. User repeats steps l-J nil trie topology is aeiineu as neeaea. 

S TTqpt ran associate the topology with devices as described in #Use Case - Define 
& Configure Devices 


Exceptions 




Alternate Flows 




Issues & Notes 





The user makes use of the Organizer Panel (or Menu Bar) and the Context Editor to add topological 
objects to the plan. By right-clinging on an element in the Organizer Panel, the user can insert a new 
element. The same operation can also be done by using the following option from the Menu Bar: 

MENU: Edit -> Insert 
Based on the element selected, a different list of devices will be shown for insertion. 
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File Edit View Changes Performance Fault Reports Tools Window Help 



PlanA 



-> Insert Site 
Insert VLAN 



- Site HQ 



III 



3.1.3 DEFINING PHYSICAL PLANS 



Pre-conditions 


User has started a new network model, or working on an existing model. 


Post-conditions 


User has imported plan information (e.g. from a .dxf file) into a network model. 


Main-Flow 


1 . User selects option to load a .dxf file (or other network model file.) 

2. JumpPad prompts user for file name/path. 

3. JumpPad opens file, and reads the data from it. 

4. The User instructs the JumpPad to associate a .dxf with a topological object (is it 
only a floor?), or to create a new topology object for the .dxf file. 

5. When selected, JumpPad displays the .dxf file as a background to the topology 
object. 

6. User would typically continue to either: 

• #Use Case - Define Topolo^v Objects 

• #Use Case - Define & Confieure Devices 


Exceptions 


4a. The topological object already has an associated .dxf file. 

1 . JumpPad replaces existing file with new one (after a warning?) 


Alternate Flows 




Issues & Notes 


• Is the .dxf more of a drawing/background, or does it give us more information like 
the list of objects and their co-ordinates? If so, then the user can be shown this list 
and asked to map them to topological elements. 



The MENU: File -> Edit -> Import option will allow the user to import a physical model. 
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Figure 2: Import Physical Plan Menu 



File Edit View Changes Performance Fault Tools Windows Help 








Import r 


Import Physical Plan 







This will open a dialogue box which allows the user to enter the file location. The user can invoke the 
browse function to see browse their directories for a file. When a file is selected, if the file extension is 
recognized its type will be shown. Otherwise, the type will be listed as "unknown" and the user can 
manually set it to the desired type. 



Figure 3: Import File Dialogue Box 



File Location: 



File Format: 



C:\Maps\HQ-Floorl.dxf 



DXF File Format 



Continue 



Browse 



i 



Cancel 



After the topological file has been imported, and the topology objects are defined, the user can start 
associating network devices with various topology objects. 
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Figure 4: Topological Display in Context Panel 




3.1.4 DEFINING & CONFIGURING DEVICES 



Pre-conditions 


User is working on a new or existing network model and wishes to define devices in it. 


Post-conditions 


User has defined one or more devices. 


Main-Flow 


1 . User adds a DP to the network plan by selecting a UI menu option. 

• The DP can be added under a topological element (in a topology view) or 
directly under the plan in a logical view. 

• If the DP is added under a topological element, it automatically uses that 
element to fill-in its location attributes. 

• If the DP is added under a plan, its location attributes are empty. These can be 
manually filled in, or the DP can be later associated with a topological 
element. 

2. User defines an IP address for the DP. 

3. The User selects a software image version for the DP. Along with the software 
image a default configuration will be associated with the DP. 

4. User fills-in the rest of the required configuration data (what is this?) for the DP. 

5. Optionally, the user manually adds location information for the DP, or associates 
the AP with a topology object. 

6. Optionally, the user instructs the JumpPad to load a default/template configuration 
for the DP. The choices for this may be based on the software version of the DP. 

7. User plans AP deployment: 

a. User graphically selects a desired coverage area that includes one or more 
DPs. 

b. The user then supplies the bandwidth, etc (what is the precise list?) for 
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the coverage area. 

c. JumpPad will generate an ideal coverage configuration, and show where 
APs should be placed. 

d. User can move the APs around and check coverage attributes. 

8. User configures one or more APs on the DP. 

a. User instructs the JumpPad to load a default/template configuration for 
the AP. 

b. User fills in other required configuration information. 

9. User repeats the above steps until the network model devices are configured as 
needed. 

10. User can choose to "deploy" or "manage" the device as described in REF. 


Exceptions 




Alternate Flows 


7-8a. User manually defines AP location: 

1 . User points to an area and instructs JumpPad tool to locate an AP there. 

2. User enters in location information. 

3. Continue with 11 in the main-flow. 


Issues & Notes 


• Do we need a default/template configuration file? Is there a choice or is it preset 
by the software release? 

• As the devices are being built, the logical GUI pane can simply show a 
containment tree of DPs and APs. If the user prefers a topological view, devices 
can be shown underneath buildings/floors, etc. 



When the User adds a new DP, a DP creation box will be used to enter in the DPs information. At this 
point, the User can choose to import data from the DP (assuming it is already deployed) or can choose to 
continue to select a software version, and enter in any necessary configuration data. 
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Figure 5: DP Creation 



Name: Default value 



IP: 



000.000.000.000 



Import from Device 



Cancel 



Software: 



Default Image 



Browse Imaees 



Management State: O Managed 



UnManaged 



Confieure DP 



Cancel 



The user is able to add devices from either the Organizational Panel or the Context Panel. The user can 
move around (drag and drop) the objects in the Context Panel. If the user has either defined a topology, the 
location attributes of the object will be updated. Alternatively, the user can manually update the location 
attributes, and the device will be automatically moved. 

Figure 6: Defining Devices in the Context Panel 



DP 53 




W 


Insert AP 
Configure Device 
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To validate the coverage, the User must select a coverage area. This could be an existing topology object 
(the user selects the object and then selects a menu option from it), or could be a coverage area that the 
User manually draws. The User can then select an option to run show the current coverage on the selected 
area or topology object. Using the supplied configuration data, JumpPad will display a coverage map. The 
user can then tweak the shown configuration as needed. If desired the user can save the changed 
configuration. 



Figure 7: Planning Menu Options on Organizational Panel 



- Site HQ 



Building 1 





riour i w 


■> Show Planned Coverage 
Plan Coverage 





By selecting a topology object or pre-defined coverage area, the user can also select an option to run a 
planning algorithm. In this case the user supplies the desired coverage requirements (e.g. desired 
bandwidth), and lets the application suggest a configuration. The user can tweak the configuration as 
needed, and save the configuration changes. 



Note that to actually apply the changed configuration to the network the user must use the normal 
deployment procedures (described in a later section.) 
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REVISION: 0.9G 



Current Coverage: 



89% 

5.5 Mbps 



Desired Coverage: 



Generate Plan 



100% 
7 Mbps 




-> Edit Parameters 



Recalculat 



Save 



Cancel 



3.1.5 IMPORTING HP OV DEVICE DISCOVERY 



Pre-conditions 


User is working on a new or existing network plan. The user has previously configured 
the JumpPad to cooperate with an HP OV installation. 


Post-conditions 


User has imported devices discovery data from HP OV, and has associated devices 
with it, 


Main-Flow 


1. The user selects a menu that lists possible HP OV interactions and choose an 
"import devices" function. 

2. JumpPad queries the HP OV installation, and collects a list of DPs and IP 
addresses. 

3. JumpPad shows this list to the user. 

4. JumpPad will also display the current configuration of the plan. 

5. The Use can create a new DP from a discovered IP address. The user will then be 
prompted to configure the device, or to import configuration from the device. 
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Exceptions 




Alternate Flows 




Issues & Notes 


• Need an easy way to batch-create DPs from a set oflP addresses. 



Figure 9: Importing Devices from HP OV 



Newly Discovered DPs 



192.168.254.1 



Create DPs 



Current Configuration 



DP 11 


192.168.255.1 


DP 12 


192.168.255.2 


DP 13 


192.168.255.3 


DP 14 


192.168.255.4 



3.1.6 WORKING ON A SAVED NETWORK PLAN 



Pre-conditions 


A user has previously worked on and saved a network plan. The plan can be in any 
state i.e. it may or may not have been used to manage a network. 


Post-conditions 


User has opened and is using a previously saved plan. 


Main-Flow 


1 . User asks JumpPad to load an existing network plan. 

2. JumpPad prompts user for path/name. This will be one logical name, and not a 
whole list. 

3. JumpPad closes the current plan (if one is open), and starts loading the new plan. 

4. The loading includes opening all files (including maps etc.) associated with the 
plan. 

5. User typically starts work on modifying/extending the plan, or simply uses it to 
start managing devices. 


Exceptions 




Alternate Flows 




Issues & Notes 
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4 DEPLOY 

Once the user has built the plan, and performed certain rules verification of the plan, he is ready to deploy 
the plan and make the configuration changes to the network. There are still two preliminary steps to 
perform before the user can start the deployment. 

1) Physical Device Setup: this will provide the minimum IP connectivity to the DPs and APs 

2) Specify software image version for the DP and APs. 

3) User hits "Deploy" to deploy the network plan to the device. 

a. JumpPad will run a list of Verification Rules based on the configuration change sets. 

b. JumpPad Push the configuration and images to the device. 

4.1 PHYSICAL DEVICE SETUP 

Before JumpPad can deploy the network plan created in the previous section the network manager 
must perform the following steps to enable basic IP connectivity to the network devices. 

4.1.1 DP SETUP 

• At the console, the user configures the IP address and default route 

a. Future will be to get this automatically via DHCP 

b. Assumptions: 

i. Has default image for APs on the file system 

ii. By default the switch is secure (i.e. doesn't pass any traffic) 
iii. By default it is a flat bridge 

• DNS parameters may need to be configured 

• Either via Telnet or at the console the user configures: 

a. SID 

b. Certificate Authority certificate(s) 

c. Authentication Methods 

i. Local/RADIUS/TACACS+ setup 

4.1.2 AP SETUP 

• ZERO config required. 

• Downloads image from DP on boot up. 
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4.2 DEPLOY CHANGES TO NETWORK 

Once the network has basic connectivity JumpPad can distribute the configurations and images 
constructed as part of the planning process. 



File Edit View Changes Performance Fault Reoort Tools Window Helo 



Site 



-> Deploy 



Building 



] Floorl ~[ 



DP1 



DP2 



Ftoor2 I 



^PortT) 

VLAN 
- ST 



By clicking on the "Deploy" option, a "Deploy" wizard will be launched as the following UI. 



4.2.1 REVIEW DEVICE CHANGES BEFORE DEPLOYMENT 

Once the user has hit "Deploy", JumpPad will display a list of changes the user has applied to the 
network, and asks the user if he wants to proceed. The user reviews the changes, and if there are any 
corrections or further changes that need to be done, he can cancel the deployment and go back the 
configuration changes again, and hits "Deploy" later on. The following is the UI for showing the list of 
configuration changes: 



Deploy Wizard 



Network Conflg Change Summary 



Device Name 


Configuration Change Set 


DPI 


Change! 
Change2 


DP2 




DP3 





Deploy Now 



Cancel 
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Pre-conditions 


User has built a network plan that consists of one or more devices. The devices have 
been physically installed and are in managed state. 


Post-conditions 


The devices are deployed and active. 


Main-Flow 


1) User selects a network plan, chooses "Changes" menu and select "deploy" 
submenu. JumpPad will bring up a Deploy wizard and display a list of the 
changes summary currently outstanding in the network plan. 

2) If the user chooses to say "Deploy Now", JumpPad will bring up the next 
Verification dialog. 

3) JumpPad will run verification rules on any changes to ensure no errors occur. 
Need to show dialog showing this running. If errors discovered the user has to 
manually select to continue (i.e. override) or cancel the deploy action. 

4) If user chooses to continue Deploy. JumpPad will start making the deployment 
changes to the devices. For each device in the network, JumpPad does the 
following: 

a. JumpPad will check if the device is in Managed State, 

i. If the "sync' state is "true", JumpPad will apply the 
configuration change and/or images set to the device 

ii. If the "sync" state is "false", JumpPad will first get the 
configuration changes from the device, and then apply the 
config change set on top, and then send the config changes to 
the device. 

b. Else if the device is in Unmanaged State 

i. JumpPad will only apply the change to the local cache and db 
copy. 

5) JumpPad display a dialog for all devices being deployed to and the progress for 
each device. 

6) If there are any error messages that coming back from the device, user will be 
able to view the error status and take appropriate actions such as Rollback 
^revenj. 


Exceptions 




Alternate Flows 




Issues 
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Deploy Wizard 



Running a list of Verification Rules 



Running Device Verification ... ok. . . 
Running VLAN Verification errors 



View Detailed 
Errors 



Continue to 
Deploy 



Cancel 



Deploy 
Wizard 



Errors while running Verification rules: 

— DP verification error 1 

— VLAN verification error2 



Ignore Error and 
Continue Deploy 



Cancel 
Deploy 



If the user clicks on View Detailed Errors, the above UI screen will be displayed. Users has a choice of 
ignoring all the errors, and continue to deploy; Or user can cancel Deploy now. User can go back to make 
the modification of the configuration changes, and then later hit "Deploy" again to rerun the Deploy 
wizard. 
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4.2.3 DEPLOY ERROR HANDLING AND ROLLBACK 

Once the user has hit the deploy action after the verifications, the following dialog will show up to 
show the progress of the deployment. Once a deployment is in progress, user can not cancel the action in 
the middle. 



Plan! Deploy Progress bar 



Deployment is in 
progress for Planl 



80% complete... 



«Details» 



If there is any errors occur in the deployment, user can select Details and he will be able to view 
the error status and details for the deployed devices. The following UI will be launched if the user clicks 
on "Details": 



Plan 1 Deploy Status 



Device Name 


State 


Status/Msg 


DPI 


Unmanaged 


Skipping.. 


DP2 


Managed 


Success 


DP3 


Managed 


Failed 



Revert Back All Changes? 



Close 



JumpPad will allow the user to revert back "ALL" the configuration changes. If the user chooses to 
"Revert back", JumpPad will use the previous saved configurations (last saved) for all devices and apply 
that to the device again. 



Pre-conditions 


User has done deployment for one or more devices in the network and there are errors 
during the deployment. 


Post-conditions 


Error conditions are handled and the devices configurations are reverted if the user 
chooses to. 


Main-Flow 


1 . After the user has hit "Deploy", there will be a progress dialog that comes up and 
display the progress of the deployment. 

2. User can not cancel the Deploy action in the middle but can view the status of the 
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deployment and possibly errors that occurred. 

3. User clicks on "Details" button, a list view of all the devices that are deployed and 
their status. 

4. If there are any failure during deployment: 

a. User can choose to say "Revert Changes" and lumpPad will prompt the 
user "Are you sure you want to revert back ALL the configuration 
changes? If the user says "yes", JumpPad will revert back the all the 
changes that have applied to the device. JumpPad will use the last saved 
configuration, and send that down to the device. 

b. If the user did not choose "Revert Changes", JumpPad should save all the 
rhanpps of the device (chanee failed^ 

1 . User can go back and fix the device problem, 

2. User goes to JumpPad to perform "deploy" again. 
JumpPad will send down the Config changes to the 
device again. 


Exceptions 




Alternate Flows 




Issues 





4.2.4 DEVICE MANAGEMENT STATE DIAGRAM 

JumpPad has the notion of the "Managed" and "Unmanaged" state. It is an attribute of the managed 
device. This is an administrative state that user decide whether he would like to manage the device or not. 
If the devices are in unmanaged state, even if the user hits "Deploy", NMS will not send down the 
configuration changes to the device. If the device is in "Managed State", JumpPad will compute all the 
change set that the user has made so far, and apply that to the device. JumpPad application will have 
another separate flag called "Sync" state in each device in order to manage whether to connecting to the 
device when first deployed or not. If the device is in "Sync" state, that mean the device has been 
synchronized before and when we do the deploy, JumpPad will sync up all the device configuration from 
the DP first, and then send down the device config change set to the device. If the device in "sync = false' 
state, that means the device has not been synchronized before, JumpPad will send down the entire 
configuration that the user has built to the device. 



The following is the state diagram of the Device State: 
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Deploy 



Case 1 : A device is in a Managed state (with sync state = true), and the user has chosen to Deploy the 
network. JumpPad will first retrieve the device config, and then send down the configuration change set to 
the DP device. 

In Step 2), when JumpPad retrieves the device config, if there are no configuration changes (from 
event log file from DP device), JumpPad will perform no operations. 

If there are configuration changes, JumpPad will probably retrieve the whole configurations from 
the device, re-apply them to the current configuration and change set, and re-run the verification 
step. If there are any errors at this point, JumpPad will prompt the user again. 



Casel :User hits "Deploy" when the device is "Managed" state and sync = true. 



User 



Jumppad 



DP Device 



1) Deploy 



2) Retrieve Device 
Config (Steo A & B) 



3) Send down 

Config 

changes 
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Case 2: A device is in a Managed state (with sync state = false), and the user has chosen to Deploy the 
network. JumpPad will send down the entire configuration change and/ or images directly to the DP device 



Case2: User hits "Deploy" when the device is "Managed" state and sync = false. 


User Jumppad DP Device 




1) Deploy 
► 


2) Send down entire 
confic/imaees to Devic< 









Case 3: A device is in an Unmanaged state (sync state = false), and the user has chosen to Deploy the 
network. JumpPad will only apply the configuration change locally at NMS level. 



Casel :User hits "Deploy" when the device is "UnManaged" state and sync = false. 



User 



Jumppad 



1) Deploy 



NMS Persistency 



2) Apply changes 
to local NMS DB 



DP Device 
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4.2.4.1 DEVICE CONNECTION STATE 

JumpPad will also keep a copy of the Device Connection State which keeps track of whether JumpPad can 
connect to the device or not. 



Device Connection State 




JumpPad will have some kind of TCP connection to the device that is up and running all the rime. JumpPad 
will be listener and register for the call back of the "Keep Alive" function. (There is some timeout 
mechanism to detect the connection loss). JumpPad will get notified if the connection is lost and take 
certain action such as coloring the Device to "red" to indicate the connection to the device is lost. 



4.2.5 SAVE SNAPSHOT VERSION OF THE CONFIGURATION 

Just a note that we need to have a place to invoke to save the "SNAPSHOT" of the network plan and in 
case the deployment of the configuration totally disabled the device, and needs to use last Saved 
SNAPSHOT to revert back to the previous state. 
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4.3 IMAGE DOWNLOAD AND UPGRADE 

NMS product will deploy new images in the normal management path as other changes. To upgrade 
the images for a set of DP/APs, JumpPad will provide a Bulk-Upgrade tool to easily upgrade all the DPs 
and APs in the network. The following steps will be performed: 

1 . User will select a list of images for the AP and DP. There is a default image for AP and DP 
images for ease of use if the user did not select the images. 

2. User will select a list of devices (for upgrade scenario) for the image upgrade to take place. 
By default, all the devices in the network will be upgraded to the selected images as 
mentioned in step 1 . 

3. JumpPad will send the image to the DP, and save it on the DP disk if DP does not already 
have the image. 

4. JumpPad will send the configuration file that refers to the DP/AP image name and version to 
DP. 



5. DP will reboot itself after the image/config file download complete if user chooses "Reboot 
Now" option. 



File Edit View Changes Performance Fault Renort Tools Window Hem 




Images 





Images 



DP Images 






Version 1 .0 



Version 1 . 1 



AP Images 




\ 


i 


Version 1 .0 





OK 



Cancel 



Selected DP image: DPI mages-Version 1.1 
Selected AP imaee: AP Imaees-Versionl.l 



Once the user has clicked on "Ok", JumpPad will be able to go to the devices in the network and query 
all the existing image versions of the devices, and launch the next UI screen: 
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Image Upgrade 



New DP Version: DPVerl . I .image! 
Device List 



New AP Version: AP Ver 1.1 image 1 



Devices 



Current Image Version 



Status 



DPI 



TZD api 

1 1 AP2 

TZ3 m 



EB-[ 



DPI 



DPVerl. Olmagel 
APVerl.OImagel 
APVerl.lImagel 
APVerl.OImagel 

DPVerl. Olmagel 



Next 



Cancel 



User can select the "Next" option if he chooses to and JumpPad will launch the next Reboot screen to 
let the user choose whether the devices will be rebooted after the image download is complete. 



Reboot Option 



New DP Version: DPVerl . 1 .image 1 
Device List 



New AP Version: APVerl .1. image 1 



Devices 



Current Image Version 



Reboot Now Option 



-ET7 



DPI 



I >■ API-- 

I I AP2 



AP3 



DPI 



DPVerl. Olmagel 
APVeTl .Olmagel 
APVerl.lImagel 
APVerl.OImagel 

DPVerl. Olmagel 



Yes 



Yes 



Upgrade 



Cancel 



Trapeze Networks Confidential 



Page 50 of 99 



JumpPad Functional Specification 



Revision: 0.9G 



Pre-conditions 


User has built a network plan that consists of one or more devices. The devices have 
been physically installed. 


Post-conditions 


The device images are downloaded and upgraded. 


Main-Flow 


1. User chooses Coniig-> "images" to select the images view and start selecting 
which images to upgrade to DP and APs. By default, JumpPad will associate with 
a default config file and image for the APs. Note that only one set of DP image 
and AP image can be selected at a time. 

2. User clicks on "Ok" once he has selected the image version to upgrade to. 

3. JumpPad displays a dialog box to show a list of devices in the network and their 
current versions of the software images that the DPs and APs are currently 
running. 

4. User selects a list of devices (including DPs and APs) that he would like to 
upgrade, and clicks on "Upgrade". JumpPad will support "Reboot Now" option to 
allow device to reboot immediately if the user chooses to. 

5. For each DP in the network, JumpPad will perform the following: 

a. JumpPad retrieves the version of each DP first and compares the version 
with what the user specifies. 

b. If the versions are different, JumpPad will first download the DP/AP 
images to the device if they are not yet on the device. 

c. Jumpr aa sends trie ^omig amju nie tnai reierences ine image iiies to me 
DP. 

d. If the user has chosen "Reboot Now" option, device will reboot itself 
with the specified new image file and replace the software images for all 
the selected APs (followed by reboot also). 

6. JumpPad will support a progress bar dialog to show all the DPs that have been 
upgraded. User can click on status on each DP to review the status. 


Exceptions 




Alternate Flows 


For first deployment, user only need to select the images before hits "Deploy" and 
NMs will assume to download all the DPs and APs with the selected version. 


Issues 
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4.3.1 REBOOT DEVICE WITH NEW IMAGE 



If user has chosen the images to download to the device and AP, but not chosen "Reboot Immediately" 
option, JumpPad allows the user to later on to reboot the APs or devices. 



File Edit View Changes Performance Fault Report Tools Window Hek> 




Images -> Download 
Reboot 





If user has chosen the Reboot option under Images, the following dialog will be launched to allow the user 
to select which AP or DP to reboot 



Reboot Option 



New DP Version: DPVerl .1. image I 
Device List 



New AP Version: APVerl.l image I 



Devices 



Current Image Version 



Reboot Now Option 



_LT 



dZL 



DPI 



1 1 



-API-. 
AP2 
AP3 



DPI 



DPVerl.OImagel 
APVeii.OImagel 
APVerl.l Image I 
APVerl.OImagel 

DPVerl.OImagel 



Yes 



Yes 



Upgrade 



Cancel 
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5 VERIFY 



Verification (or validation) occurs at different phases. This section covers a more on-demand 
verification. There is also implicit or syntactic verification when data is being entered or configured. This is 
not the focus of this section. 

[ALLAN: Long term we need to define the verification that will take place for the configuration. 
For now we should insert a placeholder for each area we will verify in the offline config view: 

Device Verification 

VLAN Verification 

RF Verification 

....etc 

As we define the rules we can update the spec to includes those rules) 
5.1 NETWORK 

[ALLAN: Any verification of the network against planned only makes sense if there are no 
outstanding changes existing in the current view. So if the user invokes either of these functions while 
changes exist, the application will prompt them to revert changes or discard changes or cancel 
operation] 



5.1.1 VERIFYING RF COVERAGE 



Pre-conditions 


A network plan is open. 


.OPost- 
conditions 


RF Coverage is performed on opened network plan. 


Main-Flow 


1. User chooses from "Changes" Menu to select "RF Coverage" menu item. 

2. If the Device is in a Managed and "Sync" states, JumpPad will retrieve actual RF 
coverage from each device. 

3. User can modify the network plan to contain an optimal RF Coverage. 

4. User can opt to view the existing RF Coverage on a detailed map. 


Exceptions 




Alternate Flows 


If the Device is in an Unmanaged state, JumpPad will run a set of verification rules 
associated with the configuration, and provide an approximation. 

Repeat Step #3 from the Main-Flow section. 


Issues & Notes 


Once any modification of the network plan is modified, JumpPad will save its 
configuration data. 



Trapeze Networks Confidential 



Page 53 of 99 



JumpPad Functional Specification 



Revision: 0.9G 



Verifying RF Coverage can be handled from within the "Changes" Menu. A new menu item called 
"RF Coverage" can be added. In term of RF Coverage, it will be measured in term of the entire Network 
Plan versus Actual Plan. 

RF Coverage attributes (there may be more. . .) 

Signal Strength 

Hotspots 

Overlaps 

Dead spots 
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File Edit View Chanees Performance Fault Reoort Tools Window Heb 



-> RF Coverage 



Network ComA 



s ?t« 



, i ltd l tq 



l | F-IOOtl 



VI2AN222 



; DP1 


- Portl 




DP2 


-Port 2 



DP 



DP2 



RF Coverage to be viewed on a Site, Building, Floor, VLAN, or DP device basis: 



RF Coverage 

RF Coverage Area: 
DP Selection: 



Srtel 



Site 1 .Bui lding2.Floo r 2.DP 1 



B 




Current Coverage Area: 

65% . 
5.5 Mbps 

RF Property based on DP 
Signal Strength: 78% 
Hirtspbt^: 3 
Overlaps: 1 
beadspots: 3 
Power Setting: 206 mW 

Proposed Coverage: 

100% 

ibiMbps 



Select "Edit Parameter..." to modify device for optimal usage. 



Edit Parameter, 



Close 



Sitel 

Site2 

Buiidingl 

Building2 

Floor 1 

Floor2 

DP1 

DP2 

VLAN 100 
VLAN200 



Any of the RED highlights depict that user should make changes to optimize usage. 
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5.1.2 VALIDATING PLANNED VS. ACTUAL DEPLOYMENT 

(ALLAN: Need example window and what we will actually cheek) 



5.2 VERIFICATION OF NETWORK CONFIGURATION DATA 
5.2. 1 VERIFYING CONFIGURATION CHANGES 



Pre-conditions 


A network plan is open and changes exist in the current view. 


Post-conditions 


The configuration changes made by the user will be verified for correctness before 
deployment 


Main-Flow 


1 . User chooses from "Changes" Menu to select "Verify" menu item. 

2. JumpPad will run a set of verification rules associated with the configuration, and 
report a list of error conditions, or miss-configuration information. 

3. User can go back to the configuration, and correct the configuration, and repeat 
the step above. 


Exceptions 




Alternate Flows 




Issues & Notes 


Note that JumpPad will only save the configuration data, not the 
performance/statistics, fault/event data. 



From either Logical or Topological View, user can perform verification against any device or the entire 
plan. 
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File Edit View Chanees Performance Fault Reoort Tools Window Helo 



-> Verify 



Network ComA 



s it« 



B < ua Jig 



. j f too ft ~| 



DP J 



'DP; 2 



YLAN222 



DP1 


-Portl 




DP2 


- Port2 



3S^> HAP 210 [ 
r orST>H AP 109 



VIAN233 
. ST 



Case #1: If there is NO Change set on the entire Network Plan. 



WARNING: 

JumpPad detects that no ChangeSet has been changed. 

Do you want to run verification against the entire 
Network Plan? 



Yes 



No 



All the devices will be verified again. User can cancel the verification process at anytime. 
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VerHlbatibn to be performed: Hetwork ComA 





Status 


Running Device Verification against: DPI 


Success 


Running Device Verification against: DP2 


Failed 


Running VL AN Verification against: VLAN222 


Failed 


Running VL AN Ver f ication against: VLAN233 


Success 







Verify Cancel Details >>> 



Verification Summary 



DP1: ok 

DP2; failed; mis- cbnfigur at ion of data 
VLAN222: failed; VL AH no longer exists 
VLAN233: ok 



<< Back Ignore Edit Finish 



Case #2: If there are some Change set on the Network Plan. 



Trapeze Networks Confidential 



Page 58 of 99 



JumpPad Functional Specification 



Revision: 0.9G 



Verification to be performed: HetWtirk -Cimify 





Status 


Running Device Verification against: DPI 


Success 


Running VLAN Verification against: VLAN222 


Failed 







Verify 



Cantei 



De^aiis>>> 



Only the Devices with Change Set are verified; others will be skipped. User can cancel the verification 
process at anytime. 



Verification Summary 



DPI: ok 

VLAN222: failed; VLAN no longer exists 



<<Back 


Ignore 


Edit 


Finish 





Once verification is performed, JumpPad will save the configuration data as well as any modification when 
the "Finish" button is pressed. 
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OPERATE 



During the normal operation of a network a manager will makes changes to the network configuration 
and images do performance analysis and check for faults. The following sections outline some of the 
operational tasks the application will provide. 

6.1 NETWORK CONFIGURATION SUPPORT 

This section will detail all of the configuration elements we will support and how. User can view, or 
modify the configuration of the device, VLAN, or plan at any time. By selecting a device or entity in the 
organizer tree, one can select from "Edit"-> "Properties" to launch any menu to view the configurations of 
the device, port, or any VLAN or Spanning tree entity. 



b,: fTrapeze Networks NMSj 




& Network Plan 
r Site 

Bu3dng 
E- © How 
B -Chassis 

Slot 1 

E-@ VLANs 

h © Device VI AN 
^■■e Device VLANj 
fiDotlx 

Authorization 
S'--@ Accounting 

Authentication 

S © Floor 



6. 1 . 1 BASIC DEVICE CONFIGURATION SUPPORT 

This section will describe the various other basic device config features we will support. Examples: 

• SNMP Trap/Community Strings 

• Telnet passwords/account/basic account management 

• RADIUS/TACACS client 
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• NTP 

• DNS 



• Port Configuration 



File Edit View Chanees Performance Fault Renort Tools Window Helo 




Properties 





When user clicks on a particular device or port, the user can select "Property" to launch the following 
dialog to view the configuration of the device or making changes: 

DPChassis: 128.10.1.2 
Name: j 

IPAddr: 

NetMask: 

NTP: 



SNMP Configuration 



Community Name: 








Trap Destination: 
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6.1.2 VLAN SUPPORT 

This section will describe what VLAN capabilities we need to configure. The purpose of the VLAN 
view is to provide an overall network view of the VLAN, and where the DP resides in relative to the VLAN 
etc. The following functions are defined: 

• Create a VLAN 

o Port Members 
o QoS Parameters 
o ACLs 

• Modify a VLAN 

• Delete a VLAN 

• Show a list of VLANs in the map VLAN->DP->Port 

File Edit View Chanees Performance Fault Reoort Tools Window Heh> 

Insert 
Properties 
Delete 

VLAN View 
VLAN1 

DPI 

DP2 

L -^~^ Port2 
VLAN2 
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(5.7.2/ CREATE A VLAN 
File Edit View Chanees Performance Fault ReDort Tools Window Helo 
Insert ->VLAN 

User can go to "Edit"o>'Tnsert->"VLAN" to add a VLAN in the network. 

The following parameters that need to be configured when user creates a VLAN: 

• VLAN Number (default 1, range: 1-1005) 

• VLAN name ("default") 

• VLAN state (active or suspended) (default: active) 

• MTU (Maximum transmission unit) (Default 1 500, range: 1 500- 1 8 1 90) 

• SAID (Security Association ID) (Default: 100001) 

• Port Group Members 

6. 1 .3 SPANNING TREE SUPPORT 

Spanning Tree algorithms provide path redundancy by defining a tree that spans all of the switches in 
an extended network and prevent the loop hole in the network. JumpPad provides the following 
capabilities: 

• Create a Spanning tree 

• Modify a Spanning tree 

• Delete a Spanning Tree 

• View a Spanning Tree 

6.1 3. 1 CREA TE A SPANNING TREE 

File Edit View Chanees Performance Fault ReDOrt Tools Window Helo 



Insert ->Spanning Tree 



User can go to "Edit"->"Insert->"Spanning Tree" to add a Spanning Tree in the network. 



The following is a list of parameters that need to be configured for a spanning tree: 



Spanning Tree ID 



Spanning Tree Type (802. Id or pvst) (default is 802. Id) 



State (enabled or disabled) (default is disabled) 
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• Forward delay time (default 1 5 seconds) 

• Hello time (default 2 seconds) 

• Maximum Aging time 

• ?? Bridge priority 

• ?? Bridge ID priority 

• ?? Port Priority 

• ?? Port cost 

• ?? Port VLAN priority 

• ?? Port VLAN cost 

6.1.4 RF SUPPORT 

The following features are desired: (See Section 5 for RF Coverage Verification) 

• Show the RF topology 

o How do we do Channel Assignments? 

o RF Coverage and bandwidth 

o Detect Interference and rouge APs 

• Hotspots 

• Overlaps 

• Dead spots 

• Overlay the RF topology with the physical topology map. 

• Allow the user to switch off the AP? Can we support this? I.e. don't disable the port in the DP 
but switch off the RF capability in the AP. Do we need to do this? 

• Configure RF related capabilities for the set of APs 

o As a whole 
o Per Ape 

o Maybe have a set of default AP parameters that if you don't override for an AP it 
uses the default parameters. That way we can configure "as a whole" by setting the 
default parameters. 



Trapeze Networks Confidential 



Page 64 of 99 



JumpPad Functional Specification 



Revision: 0.9G 




In the above RF Topology map, each color represents different channels and their 
coverage. 

6. 1 .5 QUALITY OF SERVICE SUPPORT 

This section will describe what QOS capabilities we need to configure. How do we provide adequate 
coverage and roaming across all needed areas, traffic engineering? 

6. 1 .6 ACCESS CONTROL LIST SUPPORT 

This section describes how NMS handles the ACL (Access Control List) Support and provide 
necessary configuration support. User should be able to perform the following: 

• Enable/disable (global) 

• Add an ACL (with ACL index number) 

• Remove an ACL (given ACL index number) 

• ACL Clauses?? 

o Adding a clause 
o Deleting a clause 

• Logging ACL activity 
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6.1.7 AAA SUPPORT 

JumpPad will provide necessary AAA (Authentication, Authorization, and Accounting) configurations 
for security services. 



6.1.7.1 AUTHENTICATION CONFIGURATION SUPPORT 



File Edit View Chanees Performance Fault Report Tools Window Heto 



Properties 



Site 



Building 



\ FlooM 1 



DP1 



DP2 



4 Floo72~ 



-C^_Port2j2> 

— — Authentication 



Accounting 



For each DP device, user may choose to configure the Authentication security services. The following 
parameters that need to be configured for Authentication: 

• Authentication method (Local, Tacacs, or Radius) 

o Radius Server key, IP Address, port, timeout, retransmit, dead time 

o Or Tacacs Server Key, IP Address, timeout, attempts, directed_requests 



• State (enable, or disable) 



6.1.7.2 AUTHORIZATION CONFIGURATION SUPPORT 

For each DP device, user may choose to configure the Authorization security services. The following 
parameters that need to be configured for Authentication: 

State (enabled, disabled) 
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6J.7.3 ACCOUNTING CONFIGURATION SUPPORT 

For each DP device, user may choose to view or configure the Accounting services. The following 
parameters that need to be configured for Accounting: 

State (enabled, disabled) 



6.2 MAN AGED/UNMAN AGED OPERATIONAL MODES 

For each DP device in a network, JumpPad has the notion of Managed and Unmanaged operation. 

1 . If the user selects a device and choose to perform "Unmanaged" operation, the JumpPad will 
stop talking to the selected device, and save the existing configuration to the persistent store. 
During the Unmanaged" mode, JumpPad will not apply any configuration changes to the 
device, and only save or retrieve configuration changes to the persistent store (file system in 
release 1.0). 

2. If the user chooses to apply "Managed" operation on an "unmanaged" device, JumpPad will 
first sync up the configuration data from the device first, and then apply the configuration 
changes to the device. 

3. An "undeployed" device is automatically in an "Unmanaged" mode. 



6.2.1 UNMAN AGING A DEVICE 



Pre-conditions 


An active network plan is open and the device are in managed state 


Post-conditions 


The device is in Unmanaged state 


Main-Flow 


1. User selects a device from either the organizational panel or context panel. 

2. User chooses from "Changes" Menu to select "Unmanaged" menu item, and 
clicks on ok. 

3. An dialog will pop up and says "The device will be going offline if you click 
ok" 

4. If user clicks on ok, JumpPad will save the existing configuration (only 
config, but not fault/performance data) to the persistent store 

5. JumpPad will change the state of the device to "Unmanaged" and will no 
longer talk to the device. (For example, kills the background thread for talking 
to the device). 

6. A different device icon will be associating with the unmanaged device. 


Exceptions 


If the device is already in an Unmanaged state, no operation will occur. 


Alternate Flows 




Issues & Notes 


Note that JumpPad will only save the configuration data, not the 
performance/statistics, fault/event data. 
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6.2.2 MANAGING A DEVICE 



Pre-conditions 


An active network plan is open and the device are in unmanaged state 


Post-conditions 


The device is in managed state 


Main-Flow 


1 . User selects a device from either the organizational panel or context panel. 

2. User chooses from "Changes" Menu to select "Manage" menu item (or by 
changing the attribute of the device to "Manage") 

3. If user clicks on ok, JumpPad will change the state of the device to "Managed". 
Note that "Manage" state does not mean it will goes to the device immediately. 
When a user hits "Deploy", then JumpPad will talk to the device. 

4. A different device icon will be associating with the unmanaged device. 


Exceptions 


If the device is already in a managed state, no operation will occur. 


Alternate Flows 




Issues & Notes 


Do we need to differentiate the device with "Undepolyed", or "Unmanaged" state? If a 
device is not yet deployed, can we still apply "Manage" on the device? 



How does JumpPad system version the configuration changes? In Release 1.0, JumpPad is using file- 
based system to store the configuration information. There are two options: 

• JumpPad will version each configuration changes after the user has applied the changes to the 
device only 

• Or JumpPad will periodically check-point the configuration, and save that on the persistent store 
and version that via some timestamp. 



Trapeze Networks Confidential 



Page 68 of 99 



JumpPad Functional Specification 



REVISION: 0.9G 



6.3 JUMPPAD BACKWARD COMPATIBILITY SUPPORT 

JumpPad will provide minimum backward compatibility support for previous versioned DP and AP 
devices. For example, a JumpPad 2.0 system can provide the minimum monitoring and manageability of 
DP 1.0 version. If there is any information that JumpPad 2.0 does not understand for DP 1 .0, JumpPad will 
not be able to display or support the functionality. 

6.3. 1 JUMPPAD SUPPORT OF PREVIOUS DP RELEASE 



Pre-conditions 


Installed latest JumpPad release and some of the DP in the network are still old release 


Post-conditions 


JumpPad x.x release manages DP y.y release (x.x > y.y) 


Main-Flow 


1 . User start up new JumpPad system 

2. JumpPad discovers that some of the DP are old release 

3. JumpPad will only read the data that it understood currently and discard the data it 
does not understand. 

4. JumpPad may only able to manage part of the functionality of the old DP device. 


Exceptions 




Alternate Flows 




Issues & Notes 
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6.4 JUMPPAD PERSISTENCY 

The JumpPad will store the network plans, and all associated data persistently. This includes: 

• JumpPad-level topology & device data 

• Software Images 

• Maps, graphics, etc. 

• Device configuration data 

It is desirable to not require a database. The open issue is how to support simple schemes for sharing, 
locking, synchronizations and transactions without a DB. 

The persistency is also a means of providing some JumpPad level resiliency. The goal is to leverage the 
network for as much data as possible, and hence minimize the data that needs to be replicated at the 
JumpPad level. 

The JumpPad installation will create a disk structure as described in the ^Installation section. All plans are 
stored under the "db" sub-directory. Plans are not associated with users, and are accessible by any 
authorized user. 

The User knows a plan by a given name. Internally, the network plan actually may contain a number of 
different sub-elements, which could be various types of files, configuration data, and references to software 
images. All plans share a common software image tree, and hence elements in the plan simply refer to the 
appropriate software image name. Note that this implies that if a plan is somehow shared between two 
JumpPad installations, both must have the same software images. 

6.4.1 CREATING & OPENING NETWORK PLANS 

As described in ^Starting JumpPad , when the user can create a new network plan on startup. The user 
can also access this function via the menu bar. 

• Menu Option: File -> New Network Plan. . . (Accelerator: Ctrl+N, Mnemonic: N) 

• Menu Option: File -> Open Network Plan. . . (Accelerator: Ctrl+O, Mnemonic: O) 

• Menu Option: File -> Close Network Plan. . . (Accelerator: Ctrl+L, Mnemonic: L) 
The behavior of opening an existing plan is described in gWorking On A Saved Network Plan . 



6.4.2 SAVING NETWORK PLANS 



Pre-conditions 


A plan is opened or has been newly created. 


Post-conditions 


The plan is saved to a persistent store. 


Main-Flow 


1 . User selects a menu option to save the plan. 

2. JumpPad saves all of the current data associated with the plan, including any 
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configuration change sets, to the persistent store. 


Exceptions 


la. There are no changes associated with the plan: 

1 . JumpPad will disable the "Save" menu option. 

2. The user is not able to save the plan. 


Alternate Flows 


1 a. The user invokes the "Save As" menu option: 

1 . JumpPad will prompt the user to enter a name for the plan. 

2. JumpPad will attempt to save the plan under the new name. 

3. If a plan with the same name already exists, the User will be warned of this 
condition, and asked if the intent is to replace the existing plan. 

4. JumpPad will close the current plan, and open the newly created plan for the 
user. 


Issues & Notes 




The user can access functions to save plans via the menu bar: 

• Menu Option: File -> Save Network Plan. . . (Accelerator: Ctrl+S, Mnemonic: S) 

• Menu Option: File -> Save As Network Plan. . .(Accelerator: <none>, Mnemonic: <none>) 

6.43 DELETING NETWORK PLANS 


Pre-conditions 


A plan has been created and saved. 


Post-conditions 


A plan is deleted from the persistent store. 


Main-Flow 


3 . User selects a menu function to delete a plan. 

2. JumpPad lists the existing plans. 

3. User selects a plan from the list, and hits a delete button. 

4. JumpPad removes the plan and all of its associated data from persistent store. 


Exceptions 


3a. Plan is in use (either by current user or another user?) 

1 . JumpPad detects that the plan is in use. 

2. The delete operation is not allowed. 


Alternate Flows 


• ■ There is an implication' that we- will have a mechanism to^ defect that a plan is in 
use. This implies Mmie-bort of locking scheme. Where is this"? 


Issues & Notes 





The delete function is accessed via the menu bar: 
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• Menu Option: Edit -> Delete (Accelerator: Ctrl+D, Mnemonic: d) 

6.4.4 SHARING NETWORK PLANS 

JumpPad does not provide any facility to share plans between machines. 

We have discussed the possibility of allowing the user to store the plan on a shared disk. This implies 
that during install, or as a preference, we should allow the user to point to a different "db" directory. 

We may want to consider providing a way to tar/zip a plan, so that it can be manually transferred to a 
different machine. 

6.4.5 AUTOSAVE OF NETWORK PLANS 

JumpPad will provide a user preference to enable/disable an Auto save feature. If the feature is enabled 
the user can specify a time interval. JumpPad will automatically save the plan after the specified interval. 
This information (that the save is in progress) will be displayed to the user. 



6.5 DEVICE (DP) FILE SYSTEM SUPPORT 

The DP will have a file system that supports saving various configuration and image files for both the 
DP and AP(s). 

The management product will support: 

• Download of configuration files and image files. The management product will use TFTP to 
transfer files to the device. This requires the management product to have a TFTP server 
running and it will instruct the DP to download from the server address a specific file 
representing the configuration or image file. 

• Upload of configuration files. The management product will use TFTP to transfer files from 
the device. Same method as download. 

• File system status. The management product will be able to show the contents of the file 
system, file sizes, owner (?), and amount of free disk space. 

• File system operations. The management product will be able to rename files, delete files, 
compact the file system (if supported). 

All operations will be initiated via the CLI/XML automatically by the management product. The 
file system status/contents... etc will be read via the XML interface. 
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FileSystem for DP 128.30.13 



Name 



Size 



Type 



Modified 



Owner? 



Images 



Con fig 



DP 



AP 



DP 



An 



Imagel 



Image2 



Imagel 



Image2 



Xmll 



Xml2 



Xmll 



Xml2 



User will be able to view the contents of the DP file system, and perform necessary operations on the 
file system such as renaming a file or delete a file. User can use the standard Edit-> menu to perform 
the following operations. 

• Edit Menu 

o Insert Menu Item 

Insert Menu Item provides the user the ability to add a file 

o Cut Menu Item 

This menu item allows the user to delete a file. 

o Copy Menu Item 

This menu item provides the user the capability to copy a file. 

o Paste Menu Item 
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This menu item provides the user to paste the copied file to a different 
location. 

o Rename Menu Item 

This menu item provides the user to rename the file to a different name. 

6.5.1 MANAGING DP FILE SYSTEM (ADD, DELETE FILES & DIRECTORIES) 



Pre-conditions 


JumpPad is connected to the selected DP device 


Post-conditions 


JumpPad displays the File System for a particular DP and performs certain file system 
operations. 


Main-Flow 


1 . User selects a DP device and chooses "File System" menu item under "Config" 
menu. 

2. JumpPad query DP with the XML/CLI interface for all the files and directories 
under the DP hard disks and displays the status and contents of the files such as 
file size, file type, and last modified time. 

3. User can perform file management operations such as rename the file/directory, 
delete a file/directory, or compact a file (if supported) using the standard Edit 
menu. 

4. JumpPad will send the request for the above operation via XML/CLI interface to 
the DP device. 

5. Upon receiving successful response from the DP, JumpPad presents the necessary 
changes to the user. 


Exceptions 


If the device is not connected or Unmanaged, an exception will be thrown "Can not 
communicate to the DP". 


AJternate Flows 




Issues & Notes 


Do we need to have this operation be protected by some kind of privilege? (It is kind 
of risky to have NMS system to modify the file system on DP). 
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6.6 PERFORMANCE MANAGEMENT 

This section describes the performance management capabilities within the. The performance 
parameters will be easily accessible from the configuration views of the network. All performance options 
are ONLY available on actively managed network elements. That is, a user will not be able to monitor 
performance on a configuration element that has not yet been deployed. 

JumpPad will retrieve all performance/statistics information from the device on demand and provide 
flexible way of viewing the graphs in different formats such as Graph or chart. JumpPad operations and 
actions are object-based and context-sensitive. If a user selects an object like VLAN, or port, and he can 
launch the Performance/Statistics Graphs from the Performance menu for a VLAN or port. The user can 
also launch the performance/statistics task from the right-hand side Performance tasks list. 

If the user does not select a particular object such as VLAN or DP, launching the Chassis menu will 
prompt the user to select a DP first, and then bring up the Performance graph for that object. 




• Performance Menu 

The Performance menu allows the user to retrieve and view the Performance and Statistics of 
a selected object, such as VLAN, Chassis, or port. 



VLAN Menu Item 
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o VLAN Menu Item provides the General Health, Graph and Chart Statistics, and 
potential bottlenecks for the VLAN. 

• Chassis Menu Item 

o Chassis Menu Item provides the General Health, Graph and Chart Statistics, and 
potential bottlenecks for a selected Chassis. 

• Port Menu Item 

o Port Menu Item provides the General Health, Graph and Chart statistics for a 
selected port. 

• AP Menu Item 

o AP Menu Item provides the General Health, Graph and Chart statistics for a selected 
AP (including some wireless stats). 

• Flooi\Site Menu Item 

o VLAN Menu Item provides the General Health, Graph and Chart Statistics, potential 
bottlenecks for the Container (Floor, Building or Site). 

All of the performance option panels will be polled periodically for the data. The poll rate will be 
configurable per panel but a default will be configurable as part of the application preferences. 

6.6. 1 VLAN LEVEL PERFORMANCE 

Selection: The user selects a VLAN from any organizer view and selects Performance Menu->VLAN 
for any of the submenu such as Statistics Graphs or Potential Bottlenecks. 



Performance 

VLAN Satistics Graphs 

Potential Bottlenecks 



6. 6. L 1 PERFORMANCES VLAN ->STATIST1CSG GRAPHS 

This option provides a context view with the DP's statistics in a table for all ports on the DP. There will be 
several parameters that the user can select which parameter that the user would like to see the Graphs or 
views. The user can select whether he wants to view the statistics via table or graph. 

• The following statistics will be shown per VLAN 

o What are the statistics on a VLAN level 

o Number Of Clients 
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• Each column of the table will be sort able so the user can sort based on the top packets/bytes 
in/out per DP. 

• The context view will also have the ability to display all of the data in a time graph rather than 
being tabulated. 

• The user will be able to select a port row in the table and invoke a context graph view for that 
particular port only. 



6. 6,1.2 PERFORMANCE^ VLAN -> POTENTIAL BOTTLENECKS 

This option provides a context view that lists the APs currently connected to the DP that may have 
potential bottleneck/throughput problems. This list may be empty in which case the panel will show 
none . 



6.6.2 DP LEVEL PERFORMANCE 

Selection: The user selects DP from any organizer view. AH of the performance option panels will be 
polled periodically for the data. The poll rate will be configurable per panel but a default will be 
configurable as part of the application preferences. 



Performance 

Chassis Satisfies Graphs 

Potential Bottlenecks 



6. 6.2. 1 PERFORMANCES CHASSIS ->STAT1STICS GRAPHS 

This option provides a context view with the DP's statistics in a table for all ports on the DP. There will be 
several parameters that the user can select which parameter that the user would like to see the Graphs or 
views. The user can select whether he wants to view the statistics via table or graph. 

• The following statistics will be shown per port 

o Packets/Bytes In 
o Packets/Bytes Out 
o Number Of Clients 

• Each column of the table will be sort able so the user can sort based on the top packets/bytes 
in/out per port. 
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• The context view will also have the ability to display all of the data in a time graph rather than 
being tabulated. 

• The user will be able to select a port row in the table and invoke a context graph view for that 
particular port only. 

6. 6.2.2 PEF0RMANCE->CHASS1S -> POTENTIAL BOTTLENECKS 

This option provides a context view that lists the APs currently connected to the DP that may have 
potential bottleneck/throughput problems. This list may be empty in which case the panel will show 
"none". 



6.6.3 PORT LEVEL PERFORMANCE 

Selection: The user selects a Port from any organizer view. All of the performance option panels will 
be polled periodically for the data. The poll rate will be configurable per panel but a default will be 
configurable as part of the application preferences. 



Performance 
Port --> Satistics Graphs 



6.6.3.1 FAULT->PORT->STATISTICS GRAPH 

This option provides a context view with the Port's statistics in a table for a port. There will be several 
parameters that the user can select which parameter that the user would like to see the Graphs or views. The 
user can select whether he wants to view the statistics via table or graph. 

• The following statistics will be shown for a port 

o Packets/Bytes In 
o Packets/Bytes Out 
o Number Of Clients 

• Each column of the table will be sort able 

• The context view will also have the ability to display all of the data in a time graph rather than 
being tabulated. 
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6.6.4 AP LEVEL PERFORMANCE 

Selection: The user selects AP from any organizer view and launches the menu under Performance- 
>AP related statistics options. 

Performance 

AP - -> Satistics Graphs 
Wireless Stats 



6.6.4.1 PERF0RMANCE->AP->STATJST1CS GRAPHS 

This option provides a context view with the AP's statistics in a table for all clients on the AP. 

• The following statistics will be shown per AP 
o Packets/Bytes In 

o Packets/Bytes Out 
o Number Of Clients 

• Each column of the table will be sort able so the user can sort based on the top packets/bytes 
in/out per client. 

• The context view will also have the ability to display all of the data in a time graph rather than 
being tabulated. 

• The user will be able to select a client row in the table and invoke a context graph view for 
that particular client only. 

6.6.4.2 PERFORMANCE^ AP -> WIRELESS STATS 

This option provides a context view with the AP's wireless statistics in a table for all clients on the AP. 

• The following statistics will be shown per AP 
o Wireless stats? 

• Each column of the table will be sort able so the user can sort based on the top wireless stats 
per client. 

• The context view will also have the ability to display all of the data in a time graph rather than 
being tabulated. 

• The user will be able to select a client row in the table and invoke a context graph view for 
that particular client only. 
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6.6.5 FLOOR, BUILDING, SITE LEVEL PERFORMANCE 

Selection: The user selects a floor or building or site from any organizer view. All of the performance 
option panels will be polled periodically for the data. The poll rate will be configurable per panel. For the 
purposes of this section a container can be a floor, a building or a site. The element selected will ultimately 
constrain the list of devices shown in the particular performance panel. 



Performance 

Floor.Site--> Satistics Graphs 

Potential Bottlenecks 
Client Density 



6.6.5.1 PERFORM ANCE-> FLOOR. SITE -> STATISTICS GRAPHS 

This option provides a context view with the DP/AP's statistics in a table for all clients on the floor, 
building, or site. 

• The following statistics will be shown per AP 

o Packets/Bytes In 

o Packets/Bytes Out 

o Number Of Clients 

• Each column of the table will be sort able so the user can sort based on the top packets/bytes 
in/out per client. 

• The context view will also have the ability to display all of the data in a time graph rather than 
being tabulated. 

• The user will be able to select a client row in the table and invoke a context graph view for 
that particular client only. 



6.6.5.2 PEFORMANCE->FLOOR.SITE -> POTENTIAL BOTTLENECKS 

• This option provides a context view that lists the Aps/DPs in the floor, building, or site that 
may have potential bottleneck/throughput problems. This list may be empty in which case the 
panel will show "none". 



6.6.5.3 PERFORMANCES FLOOR. SITE -> CLIENT DENSITY 

This option shows a map that has varying sizes of graphical objects that represent the number of 
clients connected to a particular point. So, an AP that has a large percentage of clients (say 50% of 
the overall number of clients) will be shown 50% larger than the others. As part of the map, the 
actual total number of clients per AP will be shown beside the object on the map. 



o 
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6.6.6 BASIC RF PERFORMANCE 
o Channel Speed (Actual) 

o Signal Strength 

» - per client 
o Signal 2 noise 

■ - per client 
o Retransmissions 

6.6.7 TUNNEL MANAGEMENT STATISTICS 
o How many tunnels? 

o % of tunnel traffic vs. non-tunnel 

o Polls of allowed clients 
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6.7 FAULT MANAGEMENT 

This section will describe the fault management capabilities and embedded features. The fault 
parameters will be easily accessible from the configuration and/or performance views of the network. 
JumpPad will retrieve all the event log information from the DP on demand (at least for release 1 .0) or 
periodically and launch the Fault/Event Viewer. JumpPad will provide a flexible filtering tool to filter 
Events/Faults by DPs, by APs, by Clients, by event category, by severity, and by date/time. DP currently 
stores a complete set of all the events/faults (probably limited by buffer size or date/time) and JumpPad will 
use bulk-transfer protocol between JumpPad-DP to retrieve the event/fault data. Currently JumpPad does 
not have callback mechanisms to automatically receive Faults/Event from the DP. Instead JumpPad will 
periodically polls DPs to retrieve the Faults/Events. Since HP-Open View provides real rime fault 
management such as alarm correlation and monitoring already, Trapeze JumpPad will not duplicate the 
same functionality as HP-OpenvView. 

In post- 1.0 release, JumpPad may choose to retrieve historical Fault/Event data from syslog daemon 
(note that some of the DP-specific events/Faults are not going to be forwarded to Syslog daemon) and use 
that data to help diagnose or correlate certain error situation and problems over time. 




• Fault Menu 



The Fault menu allows the user to retrieve and view Fault/Event log of the selected object, 
such as VLAN, Chassis, or port. The user should be able to select any object such as a DP, or 
a port, and launch the Fault Viewer for that particular object. 
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• VLAN Menu Item 

o VLAN Menu Item provides the Fault/Event Viewer for the VLAN. ??? User needs to 
select a particular VLAN and launch the Fault menu. 

• Chassis Menu Item 

o Chassis Menu Item provides the Fault/Event viewer for a selected Chassis. 

• Port Menu Item 

o Port Menu Item provides the Fault/Event Viewer for a selected port. 

• AP Menu Item 

o Port Menu Item provides the Fault/Event Viewer for a selected AP. 

• Site.Floor Menu Item 

o Port Menu Item provides the Fault/Event Viewer for a selected floor, building, or 
site. 



6/7. 1 EVENT/FAULT FILTERING CAPABILITY 

As stated in previous Menu overview section, all operations and actions are object-based and context- 
sensitive. If a user selects DP, and he can launch the Fault/Event Viewer from the Fault menu filtered out 
only by that particular DP. If a user wants to see the entire Faults/events in the network, he can select the 
entire network, and launch the Fault/Event Viewer. All the columns in the Event/Fault viewer can be 
sorted. The following is a brief screenshot of the Fault/Event Viewer launched: 



Date 


Time 


Severity 


Name 


Event ID 


Description 




01:23:54 


Critical 


skye 


9999384 


%SPANTREE-5- 
PORTDELJSUCCESS:3/2 deleted 
from VLAN 1 (PAgP Group^Rx) 















JumpPad will provide a Filter Manager in the Event/Fault viewer, and the user can use the filter 
manager to create different filtering criteria such as: 



• Last 1 hour 

• Last 24 hour 

• By Severity 

• By VLAN 

• By DP 
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• By AP 

• By Client 

• By Event Category (Event ID?) 

6.7.2 CRITICAL FAULTS THAT JUMPPAD SUPPORTS 

JumpPad shall provide some limited Fault correlation and help to monitor the general health of the 
devices. For example, JumpPad shall identify a list of critical Faults/Events, and upon receiving those, and 
use the color scheme to identify the critical alarm area of the network. JumpPad shall also identify a list of 
critical Faults/Events, and upon receiving them, and clear the colors of the critical area. (Not sure how 
much we can do in this area in Rl .0 time frame). 



6.7.3 VLAN LEVEL FAULTS 

Selection: The user selects a VLAN from any organizer view. And click on Fault->VLAN->GeneraI 
Health. 



Fault 




VLAN 


--> General Health 




Event Logs 



6.7.3.1 FAULT-> VLAN-> GENERAL HEALTH 

This option provides a context view showing the following information for the DP and all associated APs. 

• Number of Alarms (per VLAN) 

o For this data, the user will have the option to investigate the actual alarms related to 
the particular DP or an AP. 

• Number of Errors (per VLAN) 



o Same capability to investigate errors as per the alarms. 



Pre-conditions 


User selects a VLAN and launches the Fault->VLAN->General Health menu option 


Post-conditions 


A general health view dialog or frame will be launched for the VLAN 


Main-Flow 


1. JumpPad application finds all the DPs and Ports in the VLAN, and retrieves the 
faults from all of them. 

2. JumpPad application computes and summarizes number of alarms and number of 
Errors for all the devices in the VLANs. 

3. JumpPad presents the queried results and presents them in the list view format in 
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the context view. 


Exceptions 




Alternate Flows 


User selects the Fault->VLAN->Generai Heath menu and select the DP 


Issues 





6.7.3.2 FA ULT-> VLAN -> EVENT LOG 

This option provides a context view showing the list of events for the DP and all associated APs. For event, 
the user will be able to sort by AP, as well as on severity and filter on severity. 



Date 


Time 


Severity 


Name 


Event ID 


Description 




01:23:54 


Critical 


DP 


9999384 


%SPANTREE-5- 

PORTDEL_SUCCESS:3/2 deleted 
from VLAN 1 (PAgP Group Rx) 















6.7.3.3 FAULT->VLAN -> CLIENT AUTHENTICATION ISSUES 

This option provides a context view showing the list of authentication failures per VLAN for the clients. 
Included in this will be authentication failures as well as RF association failures. 



Date 


Time 


Severity 


Name 


Event ID 


Description 




01:23:54 


Critical 


DP.AP.clientl 


9999384 


Client Authentication failures 




01:23:54 


Critical 


DP 


9999384 


RF Association Failures 



6.7.4 DP LEVEL FAULTS 

Selection: The user selects DP from any organizer view. All of the fault option panels will be polled 
periodically for the data. The poll rate will be configurable per panel but a default will be configurable as 
part of the application preferences. 



Fault 




Chassis 


General Health 




Event Logs 




Client Authentication Issues 



6.7.4.1 FAULT~>CHASS1S ->GENERAL HEALTH 

This option provides a context view showing the following information for the DP and all associated APs. 
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• Current State (Up/Down) 

• Uptime (DP and APs) 

• Number of Alarms (DP and APs) 

o For this data, the user will have the option to investigate the actual alarms related to 
the particular DP or an AP. 

• Number of Errors (DP and APs) 

o Same capability to investigate errors as per the alarms. 



Pre-conditions 


User selects a DP and launch the Fault->Chassis->General Health menu option 


Post-conditions 


A general health view dialog or frame will be launch for the DP 


Main-Flow 


1. JumpPad application retrieves the faults for the DP and all APs that the DP 

manages. 

2. JumpPad application computes and summarizes number of alarms and number of 
Errors for the DP and all the APs the DP manages. 

3. JumpPad presents result in the list view format in the context view. 


Exceptions 




Alternate Flows 


User selects the Fault->Chassis->General Heath menu and select the DP 


Issues 





6. 7. 4. 2 FA ULT-> CHASSIS ->E VENT LOG 

This option provides a context view showing the list of events for the DP and all associated APs. For event, 
the user will be able to sort by AP, as well as on severity and filter on severity. 



6.7.4.3 FAVLT->CHASS1S -> CLIENT AUTHENTICATION ISSUES 

This option provides a context view showing the list of authentication failures per DP for the clients. 
Included in this will be authentication failures as well as RF association failures 



6.7.5 AP LEVEL FAULTS 

Selection: The user selects AP from any organizer view. All of the fault option panels will poll 
periodically for the data. The poll rate will be configurable per panel but a default will be configurable as 
part of the application preferences. 



Fault 

AP General Health 
Event Logs 

Client Authentication Issues 
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6. 7.5.1 FAULT->AP ->GENERAL HEALTH 

This option provides a context view showing the following information for the AP. 

• Current State (Up/Down) 

• Uptime (AP) 

• Number of Alarms (AP and clients) 

o For this data, the user will have the option to investigate the actual alarms related to 
the particular client or an AP. 

• Number of Errors (AP and Clients) 

Same capability to investigate errors as per the alarms. 

6.7.5.2 FAULT->AP -> EVENT LOG 

This option provides a context view showing the list of events for the AP. For event, the user will be able to 
sort and perform filtering on the Event Log Viewer. 

6.7.5.3 FAULT->AP-> CLIENT AUTHENTICATION ISSUES 

This option provides a context view showing the list of authentication failures per AP for the clients. 
Included in this will be authentication failures as well as RF association failures. 

6.7.6 PORT LEVEL FAULTS 



Fault 

Port General Health 
Event Logs 



6.7.6.1 FAULT->PORT~> GENERAL HEALTH 



This option provides a context view showing the following information for the selected Port. 



Current State (Up/Down) 



Uptime (Port) 
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• Number of Alarms (for the port) 

o For this data, the user will have the option to investigate the actual alarms related to 
the particular DP or an AP. 

• Number of Errors (for the port) 

o Same capability to investigate errors as per the alarms. 



Prp-ronHitinns 


DP device is connected and NMS is runnine 


Post-conditions 


A general health view dialog or frame will be launch for the Port 


Main-Flow 


1 . User selects a Port and launches Fault->Port-General Health menu. 

2. JumpPad application retrieves the state of the port (up/down), number of the 
alarms and errors related to the port from DP. 

3. JumpPad presents result in the list view format in the context view. 


Exceptions 




Alternate Flows 


User selects the Fault->Port->General Heath menu and then select the Port 


Issues 





6. 7. 6.2 FA ULT->PORT -> EVENT LOG 



This option provides a context view showing all the events for the Port. 



Date 


Time 


Severity 


Name 


Event ID 


Description 




01:23:54 


Critical 


Dp.port 


9999384 


XXX 
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6.7.7 FLOOR, BUILDING, SITE LEVEL FAULTS 

Selection: The user selects a floor or building or site from any organizer view and launches the Fault- 
>Site.Floor menu item for a list of available faults/events. 



Fault 




Site.Floor 


--> General Health 




Event Logs 




Rogue APs 




Client Authentication Issues 



6.7.7. J FAULT~> FLOOR. SITE -> GENERAL HEALTH 

This option provides a context view showing the following information for all DP/APs in the container. 

• Current State (Up/Down) 

• Uptime 

• Number of Alarms 

o For this data, the user will have the option to investigate the actual alarms related to 
the particular Floor, Site, or Building. 

• Number of Errors 

Same capability to investigate errors as per the alarms. 

6.7.7.2 FA ULT->SITE. FLOOR -> EVENT LOGS 

This option provides a context view showing the list of events for all of the DPs and all associated APs. For 
event, the user will be able to sort by AP, as well as on severity and filter on severity. 

6. 7. 7.3 FA ULT->SITE.FLOOR -> ROGUE APS 

This options provides a context view showing the list of rogue APs and allows the user to shown on the 
topology map where/ who detected them. 

6.7.7.4 FA ULT->SITE. FLOOR -> CLIENT AUTHENTICATION ISSUES 

This option provides a context view showing the list of authentication failures per DP/AP for the clients. 
Included in this will be authentication failures as well as RF association failures. 



Trapeze Networks Confidential 



Page 89 of 99 



JumpPad Functional Specification 



Revision: 0.9G 



6.8 CLIENT MANAGEMENT 

Jumppad application will provide the network manager with a more client focused view of the world. 
It will allow the user to review performance/fault/configuration related to a user defined client. User can 
select "Client Mgr" under "View" menu to bring up the Client Manager view. 

The Client Manager view will allow the user to search for a specific client on the network and relate 
that client to the network infrastructure they are currently using. The client view will also allow the user to 
perform the following functions: 

• Show where the client is currently connected and topological location in the map 

• Show where the clients have been and the client activity history 

• Show Home DP and Raoming History 

• Show the client properties such Signal strength, Channel speed, and authentication info 

• Show Client stats information 

• Show client fault information 

• Show Client RF Topology (?) 



File Edit View Chanees Performance Fault Renort Tools Window Helo 



->ClientMgr 



Query: <clientname> Search Now 



Current Location: 

Network IP: 12.1.1.1 

o V LAN-name 
DP: DP-name 
AP: AP-name 



Options: 



Show in Physical Map 

Show Activity History 
Show Current Stats 
Show Errors/Alarms 
Show Client RF 
Topology 




6.8.1 LOCATING A CLIENT 

The view will allow the user to enter a client name (i.e. user login name or PC name), upon invocation of 
the search function, the application will find a list of locations (could be more than one) the current DP/AP 
that the client is currently on. The view panel shows the current location and below the information 
provides a list of options the user may invoke to review the client 
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The client query will remember previous queries so that the user may easily find clients that they choose to 
find often. 

[We could provide a way for the user to define a list of clients they always want to find (i.e. Add to track 
list) and the track list finds all of the clients all of the time. 



Pre-conditions 


User selects a View->Client Manager 


Post-conditions 


One or more clients matching the client name are located 


Main-Flow 


1 . User enters Client by IP Address (or host name, or MAC Address) 

2. Jumppad will go to each devices in the networks, and query the location of the 
clients 

3. Jumppad displays the list of the clients to the user (there could be more than 1 
clients). Each location includes the following information: 

a. Network IP Address: 

b. DP: 

c. AP: 


Exceptions 




Alternate Flows 




Issues 


Do we need to support wildcard in search? 



The client information typically includes Network IP address, which AP the client is connected to, and 
which DP the client is connected to. 

• All of the above information will have the ability to relate/link into a more general view 
of the DP and/or APs views previously defined. 

o For example, once we have found a client, we could allow the user to say "show 
where connected in RF map" and we would bring up the RF topology map with 
the particular AP highlighted. 

6.8.2 GETTING CLIENT ACTIVITY HISTORY 

Once the user has located the client, user can choose the option of : Show Client Activity History. This 
option will allow the user to locate: 

• Home DP 

• Roaming History 

• Where the client have been (what are the locations that the client have been, and connected to) 
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Query: 


<clientname> 


Search Now. . . 


Current Location: 




Network IP: 12.1.1.1 






o VLAN-name 




DP: DP-name 




AP: AP-name 




Options: 








Show in Physical Map 




Show Activity History 




Show Current Stats 




Show Errors/Alarms 




Show Client RF 






TopoloRY 





Client Activity History: 

Home DP Location: 
Client past locations: 

location 1: 

— date-time 
—DP 

— AP 

— Roaming History 
Location 2: 

-- date-time 

— DP 
-- AP 

— Roaming History 



Pre-conditions 


A Client has been located. 


Post-conditions 


All the historical Client locations, home DP, and roaming history will be displayed. 


Main-Flow 


1 . User selects a client, and clicks on "Show Activity History" 

2. Jumppad will go to each devices in the networks, and query DP whether they have 
any information about that client, and retrieve the information. 

3. Jumppad displays the list of the client locations to the user: 

d. Client Home DP 

e. Client past locations 

f. Client roaming history 


Exceptions 




Alternate Flows 




Issues 


Do we need to support wildcard in search? 
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6.8.3 GETTING STATS BY CLIENT 

Once the user has located the client, he can view current statistics for that client. Jumppad provides 
information about the wireless statistics and performance data for each client. 

o Packets/bytes re-transmitted on current AP 

o Signal to nocise 









Query: 


<clientname> 


Search Now... 


! Current Location: 




1 - Network IP: 12.1.1.1 






o VLAN-name 




DP: DP-name 




AP: AP-name 




Options: 








Show in Physical Map 




Show Activity History 




Show Current Stats 




Show ErroTs/Alarms 




Show Client RF 






Topology 





Client Current Stats: 

Packets/bytes sent/received: 

Signal to noise: 

Packets error/retransmissions 



Pre-conditions 


A Client has been located. 


Post-conditions 


All current stastics and performance data for the client will be displayed. 


Main-Flow 


1. User selects a client, and clicks on "Show Current Statistics" 

2. Jumppad will go to the devices that the Client is currently connecting on, and 
query stats from the device.. 

3. Jumppad displays the list of the client locations to the user: 

g. Packets/bytes sent/received 

h. Signal to noise ratio 

i. Pacekts error/retransmissions 


Exceptions 




Alternate Flows 




Issues 
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6.8.4 GETTING FAULTS BY CLIENT 

User can also look at the Faults/Errors information for that client once the client is located. The following 
parameters will be collected: 

o Errors/faults on the wireless and wired network for this client 
o Number of failed attemps of authentication/logins 









Query: 


<clientname> 


Search Now... 


Current Location: 




Network IP: 12.1.1.1 






o V LAN -name 




DP: DP-name 




AP: AP-name 




Options: 








Show in Physical Map 




Show Activity History 




Show Current Slats 




Show Errors/ Alarms 




Show Client RF 






Toplogy 





Client Current Faults: 

Packets^ytes erros: 

Failed Athentication attempts: 

Etc: 



Pre-conditions 


A Client has been located. 


Post-conditions 


All current faults data for the client will be displayed. 


Main-Flow 


1 . User selects a client, and clicks on "Show Current Statistics" 

2. Jumppad will go to all the devices that the Client has been (past locations) and 

query faults/events from the device.. 

3. Jumppad displays the list of the client locations to the user: 

j. Packets/bytes errors/retransmissions 
k. Failed Athentication attempts 
1. Login failed errors 


Exceptions 




Alternate Flows 
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Issues 



6.8.5 SHOW CLIENT RF TOPOLOGY 

User can also look at the RF topology with respect with where the client is located. 
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7 



NOTES 



[Delete this section once everything is covered] 

7.1 ORGANIZER VIEWS 

This section describes the various panels/views that appear in the left-hand side of the application 
window. Each organizer will provide a variety of functions as described in each sub-section. 

7.1.1 NETWORK PLAN ORGANIZER 

The Network Plan Organizer is the parent organizer of all other views and organizers. The network 
plan organizer provides the user with a tree layout of the currently opened network plan broken down into 
four levels (map, site, building, and floor). The map level is not shown as part of the hierarchy as this is the 
root of the tree and therefore is a single instance. It is the current application context. All other views... etc 
are based on the current network plan object. 

Network Plan 

• Menu Option: File -> New Network Plan. . . (Accelerator: Ctrl+N, Mnemonic: N) 

• Menu Option: File -> Open Network Plan.. . (Accelerator: Ctrl+O, Mnemonic: O) 

• Menu Option: File -> Close Network Plan. . . (Accelerator: Ctrl+L, Mnemonic: L) 

• Menu Option: File -> Save Network Plan. . . (Accelerator: Ctrl+S, Mnemonic: S) 

• Menu Option: File -> Save As Network Plan. . .(Accelerator: <none>, Mnemonic: <none>) 

• Menu Option: Edit -> Delete (Accelerator: Ctrl+D, Mnemonic: d) 



The network plan tree view (on the Organizer View) shows the entire active network plan user has 
selected to manage. It shows the hierarchy of the Site, Building, and Floor. Within each floor, the tree view 
shows how many DPs there are in the floor, and how many APs that the DP are talking to. One can view or 
modify the attributes of a DP when a DP is selected, and view all the attributes for a port when a port is 
selected. One can also configure all the DNS entries, IP protocol configurations, and all the APs that the 
DP is connecting to. 

If the user clicks on the "DPI" node, the right side map view of the DPI node will be high-lighted to show 
where the node is in the map view (as shown below). The same applies to the AP also. 



The network plan map view shows where the DPs and APs are physically on the floor plan. One can 
choose to hide the background dxf map file if he chooses to. User should be able to select on the DP or AP 
object on the map as well to perform the same operation as in the tree view. 

Note that the user can switch to the VLAN logical view any time. 

7.2 CONTEXT VIEWS 
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7.2. 1 DXF/PHYSICAL CONTEXT 

- Shows a DXF Map and plots the positions of DPs and APs, links... etc 

7.2.2 GEOGRAPHIC CONTEXT 

- Shows a JPEG background of US? Or other? 

7.23 LOGICAL CONTEXT 

- Shows logical layout for L3, L2...etc 

7.2.4 RF CONTEXT 

Shows RF topology map for a DP or map? 

7.2.5 OBJECT CONTEXT EDITOR/VIEWER 

Allows the user to edit the currently selected object parameters in line as 
well as show the values when not editing 

• Edit a VLAN attributes or show read-only 

73 TOPOLOGY SUPPORT 

One of the main goals of the product is to provide good topology configuration for the DP/AP mix. 
This section should describe what and how we will show topology. 

73. 1 PHYSICAL TOPOLOGY 
The following features are desired: 

• For a single DP we will want to show what APs are connected to the DP. 

• What ports the APs are connected to. 

• The ability to enable/disable a particular port an AP is connected on. 

• Easily reference statistical information for a particular AP or port on the DP. 

• Shown preferably on top of a physical layout map of the building. 

• Other views could define the ''logical" physical topology. 
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7.3.2 RF TOPOLOGY 

The following features are desired: 

• Show the RF topology 

o How do we do Channel Assignments? 
o RF Coverage?? 
o Interference? 

• Hotspots 

• Overlaps 

• Dead spots 

• Overlay the RF topology with the physical topology map. 

• Allow the user to switch off the AP? Can we support this? I.e. don't disable the port in the DP 
but switch off the RF capability in the AP. Do we need to do this? 

• Configure RF related capabilities for the set of APs 

o As a whole 
o Per Ap 

o Maybe have a set of default AP parameters that if you don't override for an AP it 
uses the default parameters. That way we can configure "as a whole" by setting the 
default parameters. 

In the above RF Topology map, each color represents different channels and their 
coverage. 

7.3.3 CLIENT TOPOLOGY 

The following features are desired: 

• Show what clients are currently connected to a particular AP. 

• Overlay this topology with RF and physical topologies. 

• Per client what information do we want to show: 

o IP address? 
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o Hostname? 

o Wireless parameters? 

o "Home" DP? 



{TBD} 

As part of the main application view there will be a variety of tasks available 

1) Image management 

a. Upgrading/Downgrading AP/DPs combinations 

i . Compatibility checks 

ii. Macros across multiples of them 

2) Certificate Control 

3) Client Management 

a. Finding clients 

b. Setup QoS per client/allow/deny 

4) Topology viewers 

a. "what if scenarios" 

5) Performance/Fault Analysis 

a. Hotspots 

b. Health monitor 

c. Faults 

d. Security issues 

e. Basic throughput viewing. . .etc 

6) Configuration Parameters 

a. All of the box config that is required. 

b. Ability to import new config and download to box and make active 

c. Ability to export new config to local hard disk 
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User Management 




§ Review network Changes 



Pdrts/APs 

jMgfr P2-AP 
P3-AP 
P4-AP 
P5^AP 
Q P6-AP 
& -@ P7-AP 
@ P8-AP 
fr-fi P9-AP 

P10-AP 
& -ft Pll-AP 

a a P12-AP 

P13-AP 
i-fi P14-AP 
Sr-® P15-AP 
P1&-AP 
£-••© P17-AP 
P18-AP 
i^-"© P19-AP 
© P20-AP 
@P2t 
S P22 



R 

R 
R 
R 
R 
R 



R 
R 
R 
R 
R 
R 
R 
R 
R 
R 



Create Chassis DPI 




Attributes 



Attribute 



Value 



Managed 



Pes 



Device Name II ZOT 



Device Type fP7-7flPb*T 



Contact 



i 



Version 



I 
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nms-schedule 



Project Start: 
Project Finish: 



Mon 



Mon 




Tasks 
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25 



26 



27 



28 



Device VLAN 



Basic Verification 



Config Rules 



Mi lestone 1 Unit Tests 



Milestone 2 (Config Rev 2, Client and 
Performance) 




Config Model Updates 
(Mapping/Model/UI) 



AAA 



Dotlx 



IP Aliasing Support 



RF Planning 



RF Planning Design 



Model Definition + Persistence 



Floor Wizard (Skeleton) 



Area Wizard 



Network Design Operation Wizard 



Add New Obstacle and Loss 



Assignments 



Network Design - Finalize 
Algorithm 



Network Design - Algorithm 
Implementation 



Calculation and Display of 
Coverage 



Performance (UI/Model/Mapping) 

Net 10 Infrastructure Updates 
UI Infrastructure Updates for Perf 

Port Level 

Chassis Level 

Client 

Client Design 

Cluster Config Changes 



Cluster Model 



Mapper Support 



Device Interface Support 



View Layout Changes 



Cluster Sync Logic 



Summary GUI Page 



Find Client Wizard 
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59 



60 



62 



63 



64 



65 



66 



67 



68 



69 



i 

~12 



Network 10 Integration 



Simulate Clusters 



implement Client Queries 



Integration with embedded DP 
Simulator 



Config/Image Management (Initial) 



Design 



Jeff Learning Curve 



Spanning Tree Model/Mapping/UI 



Security Admin (Ul/Persisience) 



Kishan Learning Curve 



Milestone 2 Unit Tests 




73 



0 

pi 

m 

78 



!79 



80 



81 



82 



83 



84 



85 



86 



87 



88 



89 
90 

m 



Milestone 3 

(Verify/Fault/ConfigVersion/Reports 



Training 



Policy Updates 



Integrate Apply/Sync Menu Actions 
into Single Action and Wizard 



Resolve Policy Sync Issues in other 
functions 



Config Model Updates 



ISLConfig 



NTP Config 



DNS Client 



Logging Config 



HTTP Config 



ACL 



IGMP Snooping 



VLAN Updates 



RF Planning Updates 



Config/Image Management 



Initial NetIO API Implementation 



Net 10 Updates for versioning 
(Cfg/Image/Bootrom Push, Cfg 
Pull) 



Config File Push 



Initial UI Implementation 



Version Management Ul 



Ima&e Push 



Image Parsing 
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93 



94 



25 



126 



127 



29 



if- 



Jumppad API (Initial Development) 



Jumppad API Complete 



Verification Updates 



Rule System Design Updates 



Rule System Implementation 



Certificate Handling for DP Comms 



Boot status display in UI 



Fault (Ul/Model/Mapping) 



Initial integration of syslog viewer 
with devif 



Updates for fault UI to support 
Trapeze specific events 



Wireless Related 



Wired Related 



Milestone 3 Unit Tests 



Alpha Development 



Custom UI Views 



RF Planning Finalize 



Work Order Generation 



Floor Wizard Changes 



DXF Integration Effort 



RF Verification 



Dual Homing Support 



Physical Topology Verification 



Rules Implementation 



Final Model/Config Updates 



Fix Event Viewer Bugs 



STP Model/UI Rework 



Syslog Config/UI Updates 



Cluster Management Updates 



Load Sharing Groups/Port Groups 



AAA Updates 



ACL Mapping Updates 



AP Config Changes 



Performance UI Updates 



AP/RF Level 



CLJ/XML Import Mapping Only 



fl28| | XML/CLI Export Mappin g 



Client Management Updates 
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Find Client Wizard Updates 



Device Status Features 



Installation 



Initial Licensing Implementation 



Windows XP 



Alpha Integration Work 



Alpha QA Support 



Beta Development 



RF Planning Updates 



DWG Integration Effort 



Mobility Profile/ACL Cleanup 




Change Handler Work 



Infrastructure 



Mobility Domain 



Chassis 



MP 



Miscellaneous Changes 



Refresh From Net Cleanup 



Proxy Wizard Changes 



Boot status unhook 



1 52|| Distribute Config/Image Updates 



Run Rules On Upload/Import 



Inventory Report 



Client Management Updates 



Client History 



Client RF Topology 



Performance UI Updates 



RF Aggregation 



Client Level 



Prioritv 1 Print Features 



Print Spider V i ew 



Save Stats Table To File 



Export Event list 
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^68 
169 



170 



171 



Final Model/Con fig Updates 



Wired Authen Port Updates 



Guest VLAN Support 



13 days 



5 days 



3 days 



Mon 



Mon 




Jeff 



Yun 



172 



173 



174 



SNMP (Reduced Functionality) 
Con fig Support 



3 days 



Mon 



Jeff 



Syslog Updates 



2 days 



Thul 



Redundant Port Support 



3 days 



Monl 




Jeff 



Jeff 



175 



176 



177 



Rogue AP Detection 



17 days 



Control/Config 



5 days 




Mon 



Thu 




Kishan 



178 



Visibility 

Verification/Display/Monitoring 



12 days 



Mon 



Kishan 



179 



180 



181 



Beta System Test (includes 
Optimization/Scaling Work) 



25 days 



Monl 



Yun,Jim,Sudhir,Jeff,Kisharj 



182 



183 



184 



185 



Items That May Be Removed from 1.0 



10 days 



WPA/TKIP Config Support 



2 days 




Yun 



186 



Fril^ | | 

]LB5m BB Allan 
Wedfe lB |Allan 



187 



188 



189 



190 



191 



Priority 1 Print Features 



4 days 



Tue 



Print Stats Table 



1 day 



Tue, 



Print Stats Graph 



1 day 



Wed 




Session Roaming History 



1 day 



Floor Layout 



1 day 



Tint) I f ThM 1 
FnWW 



Allan 



Allan 



192 



193 



194 



195 



196 



197 



Priority 2 Print Features 



6 days 



Information Panel 



2 days 



RF Detect Layout 



1 day 



Client Location Layout 



day 



Client Tracking List 



2 days 




Jeff 



Jeff 



Jeff 



Mon] 



eff 



98 



199 



200 



201 



202 
203 



HP Open view Integration 



1 0 days 



Registration Files 



4 days 



Sync Up 



6 days 



HP OV Plugin Installation 



3 days 




Kishan 



Kishan 



Allan 
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204 



205 



Installation 



Solaris 




Resources 





Name 


Group 


Max Units 


Peak Units|| 


ii 


Vim 

I UJl 




i Ano/ 


I U0%| 




Jim 




100% 


100%| 


3 


Charleston 




100% 


0%| 


4 


TBD 




100% 


0%| 


5 


Allan 




100% 


300%| 


GE 


Sudhir 




100% 


100%| 


Ll 

P~ 


TBH 




100% 


0%| 


Jeff Marshall 




100% 


0% 


9 


Jeff 




100% 


100% 


1 10 


Kishan * 




100% 


100%|| 



Assignments 



Task ID 


Task Name 


Resource Name 


Work 


[~ Start 


Finish 


% Work Compl 


3 


Learning Curve 


Sudhir 


40hrs 


Mon 


' _i 




1(X 


6 


XML Mapping For Device 


Yun 


8hrs 


Mon^ 


Mon^^gl 


10( 


7 


Save Plan 


Yun 


24hrs 


Tue 


!"" J 


Thu| | 


10( 


8 


Open Plan 


Yun 


16hrs 


Fri 




Mon| | 


lot 


9 


Delete Plan 


Yun 


8hrs 


Tue| | 


TueJ 


10( 


10 


Object Model/Transactions 


Jim 


40 hrs 


Mon 


i 


Tue J 


ioc 


11 


DP Simulator Changes 


Jim 


24hrs 


Wed' 




FriJ 


1(X 


12 


Network IO 


Jim 


72 hrs 


Mon 1 




Mon J J 


10( 


14 


New Plan 


Charleston 


40 hrs 


Monj 






10C 


15 


Open Plan 


Charleston 


16 hrs 


Mon 


i- 


TueJ 


10C 


16 


Save Plan 


Charleston 


16 hrs 


Wed| 




Thu] | 


10C 


17 


Save As Plan 


Charleston 


8 hrs 


Fri 1 


. 


Fri l B 


10C 


18 


Delete Plan 


Charleston 


16 hrs 


Mon , 




_Tue^p3| 


100 


19 


Basic Wizard Updates 


Allan 


24 hrs 


Mon 




_Wed^^^ 


100 


20 


Revert 


Allan 


16 hrs 


Th"K!§l 




100 


21 


Deploy 


Allan 


40 hrs 


Monj 


: 


Fri ■ 1 


100 


1 




1 




II- 1 
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22 



22 



24 



25 



27 



28 



28 



28 



28 



28 



31 



32 



33 



35 



36 



37 



39 



40 



41 



42 



43 



45 



46 



47 



48 



50 



52 



54 



55 



56 



View Layouts and UI 
Navigation 



View Layouts and UI 
Navigation 



Basic Device and Ports 



Device VLAN 



Config Rules 



Milestone 1 Unit Tests 



Milestone 1 Unit Tests 



Milestone 1 Unit Tests 



Milestone 1 Unit Tests 



Milestone 1 Unit Tests 



AAA 



Charleston 



SO hrs 



Mon 



Dotlx 



IP Aliasing Support 



RF Planning Design 



Model Definition + Persistence 



Floor Wizard (Skeleton) 



Area Wizard 



Network Design Operation 
Wizard 



Add New Obstacle and Loss 
Assignments 



Network Design - Finalize 
Algorithm 



Network Design - Algorithm 
Implementation 



Calculation and Display of 
Coverage 



Net IO Infrastructure Updates 



UI Infrastructure Updates for 
Perf 



Port Level 



Chassis Level 



Client Design 



Cluster Model 



Mapper Support 



Device Interface Support 



View Layout Changes 



Cluster Sync Logi c 



10i 
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Summary GUI Page 



Find Client Wizard 



Simulate Clusters 



Implement Client Queries 



Integration with embedded DP 
Simulator 



Design 



Design 



Jeff Learning Curve 




Spanning Tree 
Model/Mapping/UI 



Integrate Apply/Sync Menu 
Actions into Single Action and 
Wizard 



Resolve Policy Sync Issues in 
other functions 



Security Admin 
(Ul/Persistence) 



Kishan Learning Curve 



Milestone 2 Unit Tests 



Milestone 2 Unit Tests 



Milestone 2 Unit Tests 



Milestone 2 Unit Tests 



Milestone 2 Unit Tests 



Training 



ISL Config 



NTP Config 



DNS Client 



Logging Config 



HTTP Config 



ACL 



IGMP Snooping 



VLAN Updates 



RF Planning Updates 



nitialNet.ro API 
Implementation 



Net 10 Updates for versioning 
(Cfg/Image/Bootrom Push, Cfg 
Pull) 



Config File Push 



Initial UI Implementation 
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90 ||Version Management UI 



91 



92 



Image Push 



Image Parsing 




93 



94 



96 



97 



98 



99 



101 



103 



104 



105 



105 



105 



105 



105 



105 



107 



109 



10 



111 



113 



114 



115 



117 



118 



120 



121 



Jumppad API (Initial 
Development) 



Jumppad API Complete 



Rule System Design Updates 



Rule System Implementation 



Certificate Handling for DP 
Comms 



Boot status display in UI 



Initial integration o f syslog 
viewer with devif 



Wireless Related 



Wired Related 



Milestone 3 Unit Tests 



Milestone 3 Unit Tests 



Milestone 3 Unit Tests 



Milestone 3 Unit Tests 



Milestone 3 Unit Tests 



Milestone 3 Uni t Tests 



Custom UI Views 



Work Order Generation 



Floor Wizard Changes 



DXF Integration Effort 



Dual Homing Support 



Physical Topology Verification 



Rules Implementation 



Fix Event Viewer Bugs 



STP Model/Ul Rework 



Syslog Config/Ul Updates 



Chister Management Updates 



Load Sharing Groups/Port 
Groups 



122 



123 



124 



126 



127 



AAA Updates 



ACL Mapping Updates 



AP Config Changes 



AP/RF Level 



CL1/XML Import Mapping 
Only 
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128 



130 



131 



133 



134 



135 



135 



135 



135 



136 



136 



136 



136 



136 



138 



139 



140 



143 



144 



145 



146 



149 



150 



151 



152 



153 



154 



157 



158 



161 



162 



165 



166 



167 



170 



171 



172 



XML/CLI Export Mapping 



Find Client Wizard Updates 



Initial Licensing 
Implementation 



Device Status Features 



Windows XP 



Alpha Integration Work 



Alpha Integration Work 



Alpha Integration Work 



Alpha Integration Work 



Alpha QA Support 



Alpha QA Support 



Alpha QA Support 



Alpha QA Support 



Alpha QA Support 



RF Planning Updates 



DWG Integration Effort 



Mobility Profile/ACL Cleanup [[Kishan 



Infrastructure 



MP 



Mobility Domain 



Chassis 



Refresh From Net Cleanup 



Proxy Wizard Changes 



Boot status unhook 



Distribute Config/Image 
Updates 



RF Aggregation 



Client Level 



Run Rules On Upload/Import 



Inventory Report 



Client History 



Client RF Topology 



Print Spider View 



Save Stats Table To File 



Export Event list 



Wired Authen Port Updates 



Guest VLAN Support 



SNMP (Reduced Functionality) 




Microsoft 
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I?: 



174 



177 



178 



181 



181 



181 



181 



181 



185 



188 



190 



191 



194 



195 



196 



197 



200 



201 



202 
15T 



Syslog Updates 



Con fig Support 



Redundant Port Support 



Control/Config 



Jeff 



Jeff 



Beta System Test (includes 
Optimization/Scaling Work) 



Beta System Test (includes 
Optimization/Scaling Work) 



Visibility 
Verification/Display/Monitoring 



Beta System Test (includes 
Optimization/Scaling Work) 



Beta System Test (includes 
Optimization/Scaling Work) 



Beta System Test (includes 
Optimization/Scaling Work) 



WPA/TKIP ConJig Support 



Yun 



Kishan 



Kishan 



Jim 



Sudhir 



Jeff 



Kishan 




200 hrs 



200 hrs 



200 hrs 



200 hrs 



200 hrs 



Print Stats Table 



189 Print Stats Graph 



Mon 



Moni 



Mon I 



Session Roaming History 



Floor Layout 



Information Panel 



RF Detect Layout 



Client Location Layout 



Client Tracking List 



Registration Files 



Sync Up 



HP OV Plugin Installation 
Solaris 



Fri! 




Microsoft Home Page 
MicrosofLPLpject ±forne_Pag.e 



Exhibit C 



Diligence 
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raye i 01 



nms-schedule 



r> • » o» ^ Mon 
Project Start: 

Project Finish: Mon 




Tasks 



1D| 


Task Name Duration 


Start 


Finish 


Resource Names 




Implementation 237 days 


Mon 1 




Fri 1 






U 


Milestone 1 (Basic Workflow) 


33 days 


Mon 1 




Fri 1 






Learning Curve 


5 days 


Mon' 




Fri| 




Sudnir 




Infrastructure Work 


Zj days 


Mon 1 




Tuej 






p] 

m 


Persistence 


7 days 


Mon| 




Tuej 






XML Mapping For Device 


1 day 


Mon| 




Mon| 1 


i un 


Save Plan 


3 days 


Tue' 




Thu 1 




i un 


ll 8 II Open Plan 


2 days 


Frifl 


Mon! 




Yun 


m 


Delete Plan 


1 day 


Tuej 




Tue ( 




Yun 


10 1 


Object Model/Transactions 


5 days 


MoiV 




Tue] 




Jim 


liij 


DP Simulator Changes 


3 days 


Wed 




Fri 




Jim 


pi 


Network 10 


9 days 


Mon 




Moi 


il 1 


Jim 


UI 


25 days 


Mon 




Tue 






New Plan 


5 days 


Monf 1 


Fri1 




Charleston 


HIT 


Open Plan 


j 2 days 


MonJ I 


Tuep I 


Charleston 


16 


Save Plan 


2 days 


Wed 




Thu 




Charleston 


1 17 


Save As Plan 


1 day 


Fri 




Fri 




Charleston 


18 


Delete Plan 


2 days 


Mon 




Tue 


Charleston 


19 


Basic Wizard Updates 


3 days 


Monj^BB 


Wed 




Allan 


20 


Revert 


2 days 


Thu 




Fn| I 


Allan 


21 


Deploy 


5 days 


Mon 




Fri^| § 


Allan 


22 


View Layouts and UI Navigation 


1 0 days 


Mo 


ill 1 


Ttiej| | 


Charleston, Sudhir 


23 


Basic Config Model 
(Mappinp/Model/Ul) 


1 4 days 


Mon 




Mo)4HBI 




24 


Basic Device and Ports 


12 days 


WcdflH 


Mo 


1 ■ 1 


Yun 






ir ~r i 
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1 25 


[_ Device VLAN 


J 10 days 


Mon 


i^flil Fri 




|Sudhir 


26 


Basic Verification 


5 days 


M on 


I Fri 






| 27 
|~28~ 


Config Rules 


5 days 




| Fri 




| Allan 


Milestone ] Unit Tests 


5 days 


Mon 


t 


| Fri 




[ Yun, Jim,Charleston, Allan 


29 


lTiiicMujic' jL ^v^uiiiig jxcvl, v. iieiii anci 
Performance) 












55 days 


Mon 




| Mon MM 


I 












Config Model Updates 
(M a ppin g/M od el/U I) 


43 days 


Wed 


mm 


MonMH 


! 


hii 


AAA 


6 days 


Wed 




Wed] 


Yun 


1 32 


Dotlx 


8 days 


Th 
1 11 




Mon 




Yun 


1 33 


IP Aliasing Support 


2 days 


Fri 




Mon 




Kishan 


1 34 


RF Planning 


45 days 


Mon 




Mon( 


_i 


pi 


RF Planning Design 


7 days 


Mon 




Tue] 


Sudhir 


1 36 


Model Definition + Persistence 


5 days 


Wei 


s 




Sudhir 


1 37 


Floor Wizard (Skeleton) 


5 days 


Wed 




Tue] 


Sudhir 


| 38 


Area Wizard 


2 days 


Wedj 


B 


Tlnul | 


OUUJJ1J 


| 39 


Network Design Operation Wizard 


5 days 


Fri 


Thu] 




Sudhir 


1 

40 


Aua i\ew UDStacJe and Loss 
Assignments 


3 days 




Wee 




Sudhir 


1 

4. 


iNervvorK uesign - rinalize 
Algorithm 


5 days 




WedJMHf 


Sudhir 


42 


jNerworK uesign - AJgontlini 
Implementation 


8 days 




MonflMHj 


Sudhir 


43 


Calculation and Display of 
Coverage 


5 days 


Tu£*HHH| 


MonfBBBjJ 


Sudhir 


[47 


Performance (UI/Model/Mapping) 


1 9 days 


IBBE ^ j 


Thu| | 




Net 10 Infrastructure Updates 


10 days 


Mon^ |j 


Fri 




Jim 


1 46 


Ul Infrastructure Updates for Perf 


3 days 


Mon| | 


Wed^ | 


Allan 


47 


Port Level 


8 days 


Thul | 


Mon] ■ 


Allan 


[ 48 
|49~ 


Chassis Level 


8 days 


Tuel 




Thu] ] 


Allan 


Client 


1 5 days 


Tue! 


1 Tue l 1 




1 50 

1 ■ i 


Client Design 


5 days 


Tue| 


I Mon^ 


1 


Yun 


I 1 


Cluster Config Changes 


5 days 


Monl 


1 Frit 


1 






Cluster Model 


2 days 


Tue j 




WeilJ | 


Yun 


53 


Mapper Support 


1 day 


Mon] 






Yun 


54 


Device Interface Support 


2 days 


Tue| 




Wed 1 I . 


Jim 


55 


View Layout Changes 


2 days 


Thul 1 


Fn| 


Yun 




Cluster Sync Logic 


4 days 


Thuj 




Wed] 1 . 


lim 


57 


Summary GUI Page 


2 days 


Tue 


1 


Wed] I' 


Yun 


58 

1 11 


Find Client Wizard 

11 


3 days 

11 


T! i| | 

11 


Mon' 


II 


Yun 
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60 



61 



62 



63 



Network 10 integration 



Simulate Clusters 



Implement Client Queries 



Integration with embedded DP 
Simulator 



Config/Image Management (Initial) 



Design 



JefY Learning Curve 



Spanning Tree Model/Mapping/UI 
Security Admin (Ul/Persistence) 



Kishan Learning Curve 



Milestone 2 Unit Tests 



Milestone 3 

(Verify/Fault/ConfigVersion/Reports 



Training 



Policy Updates 



Integrate Apply/Sync Menu Actions 
into Single Action and Wizard 



Resolve Policy Sync Issues in other 
functions 



Config Model Updates 



ISL Config 



NTP Config 



DNS Client 



Logging Config 



HTTP Config 



ACL 



IGMP Snooping 



VLAN Updates 



RP Planning Updates 



Config/Image Management 

Initial Ne tIO API Im plementation 

Net 10 Updates for versioning 
(Cfg/jmage/Bootrom Push, Cfg 
Pull) 



Config File Push 



Initial UJ Implementation 



Version Management UJ 



Image Push 



Image Parsing 
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93 



94 



95 



96 



97 



98 



99 



100 



101 



102 



102 



104 



105 



06 



107 



108 



109 



110 



111 



113 



114 



115 



116 



117 



118 



119 



120 



121 



122 



23 



124 



125 



126 



27 



28 



29 



Jumppad API (Initial Development) 



lumppatl API Complete 



Verification Updates 



Rule System Design Updates 



Rule System Implementation 



Certificate Handling for DP Comms 



Boot status display in UI 



Fault (UI/Model/Mapping) 



Initial integration of syslog viewer 
with devif 



Updates lor fault UI to support 
Trapeze specific events 



Wireless Related 



Wired Related 



Milestone 3 Unit Tests 



Alpha Development 



Custom UI Views 



RF Planning Finalize 



Work Order Generation 



Floor Wizard Changes 



DXF Integration Effort 



112 RF Verification 



Dual Homing Support 



Physical Topology Verification 



Rules Implementation 



Final Model/Config Updates 



Fix Event Viewer Bugs 



STP Model/UI Rework 



Syslog Config/UI Updates 



Cluster Management Updates 



Load Sharing Groups/Port Groups 



AAA Updates 



ACL Mapping Updates 



AP Conllg Changes 



Performance UI Updates 



AP7RF Level 



CLJ/XML Import Mapping Only 



XML/CLI Export Mapping 



Client Management Updates 
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[31 



I 132 



133 



134 



135 



136 



137 



138 



139 



140 



Find Client Wizard Updates 



Device Status Features 



Installation 



Initial Licensing Implementation 



Windows XP 



Alpha Integration Work 



Alpha QA Support 



Beta Development 



RF Planning Updates 



DWG Integration Effort 



Mobility Profile/ACL Cleanup 



3 days 



10 days 



days 



8 days 



3 days 



10 days 



15 days 



50 days 



12 days 



3 days 



4 days 



Mon 



Wed 



Wed 



Mon, 



Mon] 



Mon 



Moni 



Wed] 



Mon] 




Mon] 



Yun 



Jeff 



Kishan 



Kishan 



Jhn,Yun,Jeff,Kishan 



YunJim,Sudhir,Jeff,Kisha 



Sudhir 



Sndhir 



Kishan 



141 



142 



143 



144 



145 



146 



Change Handler Work 



5 days 



Mon^ 



Infrastructure 



2 days 



Mon 



Mobility Domain 



5 days 



Mon] 



Chassis 



1 day 



Wed 



MP 



2 days 



Thu] 




Jim 



Jeff 



Jim 



Jim 



147 



148 



149 



150 



151 



152 



153 



154 



Miscellaneous Changes 



1 2 days 



Refresh From Net Cleanup 



3 days 



Proxy Wizard Changes 



2 days 



Boot status unhook 



1 day 



Distribute Config/Image Updates 



1 day 



Run Rules On Upload/Import 



1 day 



Inventory Report 



4 days 




Jim 



Jim 



Jim 



Jim 



Jim 



Jim 



155 



156 



157 



158 



Client Management Updates 



9 days 



Mon 



Client History 



4 days 



Mon 




Client RF Topology 



5 days 



Fri 




Yun 



Yun 



59 



160 



62 



Performance XJI Updates 



9 days 



Wed 



RF Aggregation 



4 davs 



Wed 




Client Level 



5 davs 



Tuc 



Mon 



Allan 



Allan 



163 



64 



65 



66 



167 



Prioritv ] Print Features 



4 days 



TueJ 



Prinl Spider View 



Save Stats Table To File 



Export Event list 



1 dav 



Tuej 



2 days 



day 




Wed 



Allan 



Allan 



Allan 
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168 
~\69 



170 



i71 



172 



Final Model/Config Updates 



Wired Authen Port Updates 



Guest VLAN Support 



SNMP (Reduced Functionality) 
Con fig Support 



1 3 davs 



5 davs 



3 days 



3 days 



Mon 




Mon 



Mon, 



Wedggjj 



Jeff 



Yun 



Jeff 



173 



174 



175 



176 



177 



178 



Syslog Updates 



2 days 



Thul 



Redundant Port Support 



3 days 



Monl 




Jeff 



Rogue AP Detection 



17 days 



Control/Config 



5 days 




Mon 



Thu 




Visibility 

Verification/Display/Monitoring 



12 days 



Monl 



Jeff 



Kishan 



Kishan 



179 



180 



181 



Beta System Test (includes 
Optimization/Scaling Work) 



25 days 



Monl 



YunJim,SudhirJeff,Kisha 



182 



183 



184 



185 



Items That May Be Removed from 1.0 



10 days 



WPA/TKIP Config Support 



2 days 




Yun 



186 



187 



188 



189 



190 



191 



Priority 1 Print Features 



4 days 



Print Stats Table 



1 day 



Print Stats Graph 



1 day 



Wed^ ^i 



Session Roaming History 



1 day 



Floor Layout 



1 day 



WedpjH 



Allan 



Allan 




Allan 



Allan 



192 



193 



194 



195 



196 



197 



Priority 2 Print Features 



6 days 



Information Panel 



2 days 



RF Detect Layout 



1 day 



Client Location Layout 



1 day 



Client Tracking List 



2 davs 




Jeff 



Jeff 



Jeff 



Mon] 



Jeff 



1 98 



199 



200 



1201 



202 
203 



HP Open view Integration 



1 0 days 



Registration Files 



4 days 



Sync Up 



6 days 



HP OV Plugin Installation 



3 days 




Kishan 



Mon 



Kishan 



Allan 
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204 



205 



Installation 



Solaris 



5 days 



5 days 



Tue' 




Resources 



ID 


Name 


Group 


Max Units 


Peak Units 


1 


Yun 




100% 


100% 


2 


Jim 




100% 


100% 


3 


Charleston 




100% 


0% 


4 


TBD 




100% 


0% 


5 


Allan 




' 100% 


300% 


6 


Sudhir 




100% 


100% 


7 


TBH 




100% 


0% 


8 


Jeff Marshall 




100% 


0% 


9 


Jeff 




100% 


100% 


to 


Kishan rv 




100% 


100% 



Assignments 
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22 


View Layouts and UI 
jNcivjgciijon 


Charleston 


SO his 


Mon 


Tue 


mm 


„ 


22 


V.ievV I.ydyOUTS clfKI UI 

Navigation 


Sudhir 


80 hrs 


Mo? 








24 


Basic Device and Ports 


Yun 


96 hrs 


Wed 




Monpl 




25 


Device VLAN 


Sudhir 


80 hrs 


Mon 


5 

mm 


Fri 




1 ( 


27 


Config Rules 


Allan 


40 hrs 


Mon 


Fri 




1 ( 


28 


Milestone 1 Unit Tests 


Yun 


40 hrs 


Mon 




Fn| 


If 


28 


Milestone 1 Unit Tests 


Jim 


40 hrs 


Mon 




Fri 




If 


28 


Milestone 1 Unit Tests 


Charleston 


40 hrs 


Mon] 




Fri 




If 


28 


Milestone 1 Unit Tests 


Allan 


40 hrs 


Mon 


Fri 




1 f 


28 


Milestone 1 Unit Tests 


Sudhir 


40 hrs 


Mon^(|||l|| 


Fri 




If 


! 31 


AAA 


Yun 


48 hrs 


Wedl 




We< 




1 f 


32 


Dotlx 


Yun 


64 hrs 


Thi 




Mon 




If 


33 


IP Aliasing Support 


Kishan 


16 hrs 




Mon| | 


1 f 


35 


RF Planning Design 


Sudhir 


56 his 


Mon 




Tue| | 


1 f 


36 


Model Definition + Persistence 


Sudhir 


40 hrs 


Wee 




i Tue| | 


1C 




rloor Wizard (Skeleton) 


Sudhir 


40 his 


Wed] 




Tue 




1C 


38 


Area Wizard 


Sudhir 


16 hrs 


Wed lSllB 


Thu< 




IC 




Network Design Operation 
Wizard 












39 


Sudhir 


40 hrs 


Fn| 




Thuj 




1C 


















40 


Add New Obstacle and Loss 
Assignments 


Sudhir 


24 hrs 




Wed SM 


IC 


A 1 

41 


Network Design - Finalize 
Algorithm 


Sudhir 


40 hrs 


Thu0H| 


Wedj 




10 




Network Design - Algorithm 
implementation 














42 


Sudhir 


64 hrs 


Thu| 




Mon' 




10 




















Calculation and Display of 
coverage 
















43 


Sudhir 


40 hrs 


Tue{ 




Mon| 




10 




iNei i\j lnirasiructure updates 


Jim 


oU nrs 


Mon] | 


Fri|| | 


10 


46 


uj inrrasirucTure updates lor 
Perf 


Allan 


24 hrs 


Mon| | 


WedPP] 


10 


47 


Port Level 


Allan 


64 hrs 


Thi 




Mon| | 


10 


48 


Chassis Level 


Allan 


64 hrs 


Tue| 




Tm, IS§S5* 


10 


50 


Client Design 


Yun 


40 his 


TueJ 




Mon| | 


10 


52 


Cluster Model 


Yun 


16 hrs 


Tucj 


Wed| | 


10 


53 


Mapper Support 


Yun 


8 hrs 


Mor| § 


Mon] 




10 


54 | 


Device Interface Support 


Jim 


16 hrs 




Wed] 




10 


55 


View Layout Changes 


Yun 


1 6 In s 


ThuPSi 


Fri] 




10 


56 


Cluster Sync Logic 


Jim 


32 hrs 




Wed || 


10 








II II 1 
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57 



58 



60 



61 



Summary GUI Page 



Find Client Wizard 



Simulate Clusters 



Implement Client Queries 



Yun 



Yun 



Jim 



Jim 




62 



Integration with embedded DP 
Simulator 



Jim 



64 



64 



65 



Design 



Yun 



Design 



Jim 



Jeff Learning Curve 



Jeff 



66 



Spanning Tree 
Model/Mapping/UI 



Jeff 



67 



Security Admin 
(Ul/Persistence) 



Jeff 



68 



69 



69 



69 



69 



69 



71 



Kishan Learning Curve 



Kishan 



Milestone 2 Unit Tests 



Yun 



Milestone 2 Unit Tests 



Sudhir 



Milestone 2 Unit Tests 



Jim 



Milestone 2 Unit Tests 



Jeff 



Milestone 2 Unit Tests 



Training 



Kishan 



Sudhir 



73 



Integrate Apply/Sync Menu 
Actions into Single Action and 
Wizard 



Allan 



74 



Resolve Policy Sync Issues in 
other functions 



Allan 



76 



77 



78 



79 



80 



81 



82 



83 



84 



ISL Config 



Jeff 



NTP Config 



Jeff 



DNS Client 



Jeff 



Logging Config 



Jeff 



HTTP Config 



Jeff 



ACL 



Kishan 



IGMP Snooping 



Allan 



VLAN Updates 



Sudhir 



RF Planning Updates 



Sudhir 



86 



Initial NetIO API 
Implementation 



Jim 



87 



88 



89 



Net 10 Updates for versioning 
(Cfg/Image/Bootrom Push, Cfg 
Pull) 



Jim 



Config File Push 



Jim 



Initial Ul Implementation 



Yun 
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96 



97 



Version Management UI 



Imane Push 



Image Parsing 



Jumppad API (Initial 
Development) 



Jumppad API Complete 



Rule System Design Updates 



Rule System Implementation 
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99 



Certificate Handling for DP 
Comms 



Boot status display in UI 



101 



103 



104 



105 



105 



105 



105 



105 



105 



107 



109 



110 



111 



113 



114 



115 



117 



118 



119 



120 



121 



122 



123 



124 



126 



127 



Initial integration of syslog 
viewer with devif 



Wireless Related 



Wired Related 



Milestone 3 Unit Tests 



Milestone 3 Unit Tests 



Milestone 3 Unit Tests 



Milestone 3 Unit Tests 



Milestone 3 Unit Tests 



Milestone 3 Unit Tests 



Custom UI Views 



Work Order Generation 



Floor Wizard Changes 



DXF Integration Effort 
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Rules Implementation 



Fix Event Viewer Bugs 



STP Model/UI Rework 



Syslog Config/UI Updates 



Cluster Management Updates 
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Groups 



AAA Updates 



ACL Mapping Updates 



AP Coniig Changes 



AP/RF Level 



CLI/XML Import Mapping 
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Microsoft Project Exported Information 



Page 1 1 of 



I28 



130 



XML/CLI Export Mapping 
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Alpha Integration Work 



Alpha Integration Work 



Alpha QA Support 



Alpha QA Support 



Alpha QA Support 



Alpha QA Support 



Alpha QA Support 



RF Planning Updates 



DWG Integration Effort 



Mobility Profile/ACL Cleanup 
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Refresh From Net Cleanup 
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Boot status unhook 
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Run Rules On Upload/Import 
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1 RF PLANNING 

1.1 RF PLANNING 

This section covers the understanding of Requirements for RF Planning Tool and details the design. 
The primary goals of this feature in Jumppad are: 

• Ability to create a coverage Area 

• Ability to design Wireless network 

• Ability to automatically assign channels to different Access points 

• Ability to view/edit the generated location of the Access Point and Data Point 

• Ability to define obstacles in floor with attenuation factors 

• Ability to specify a channel that a foreign Access Point is using ( if it is not discovered by AP) 

• Ability to deploy the generated configuration and then collect data to show coverage 

• Ability to visibly see the difference in deployed network vs. actual coverage information 
obtained from Access Point 

• Ability to visibly see the desired network and the coverage obtained by a "single Access Point 
failure" 

• Ability to show clients on topoglogy map ( this will be an on-demand operation) 

• Ability to show Rogue Access Points discovered by Trapeze devices and allow the user to 
select it and mark it as a foreign Access Point 

• Ability to track the location of a particular wireless user 



1.2 USE CASE SCENARIOS (OUTDATED: PLEASE REFER TO USER MANUAL) 
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Following diagram depicts te scenarios from a user-point of view 



Floor Wizard Overview 




Figure 1: Overall Scenario 

The network planner would do the following: 

1 . Define / update a Floor 

2. Define /update the propagation losses on various obstacles 

3. Define a coverage area 

4. Request Network to be designed. The planner may choose to specify certain constraints in order to 
generate the RF plan. 

5. Make changes to the generated plan by moving the pre-defined locations of Access Points, 
redefining certain constraints or changing the profile information and Regenerate the RF Plan 

6. Request for automatic channel allocation. 
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7. Save or deploy the changes instantaneously. 
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1.2.1 FLOOR DEFINITION 

Launch Points: 

• In Binding Layout or with a building selected: 
Insert -> Floor 

• With that Particular Floor selected 
Edit Properties 

The definition of floor shall be controlled by a wizard as defined by the following scenario: 




Figure 2: Floor Definition 
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The pages involved are as follows 
Pagel : Setup 

Page2: Edit Content 

Page3: Define Coverage 

Page4: Compute and Place 

Page5: Reports 



The tool bar shown in the picture above has the following operations: 



Icon 


Description 




Open/Close Layers Pane 




Zoom In 


H 


Zoom Out 




Print 




Use a circle drawing to draw 
free draw 
insert an area 
insert a RF Obstacle 




Use a Rectangle drawing to draw 

free draw j 
insert an area 
insert a RP Obstacle 



Trapeze Networks Confidential 



Page 8 of 40 



NMS Software design Specification 



Revision: 0.4 







Use a Polyline drawing to draw 
free draw 
insert an area 
insert a RF Obstacle 






Use a Parallelogram drawing to draw 
free draw 
insert an area 
insert a RF Obstacle 






Use a Line drawing to draw 
free draw 

insert a RF Obstacle 




Insert the location of a wiring closet 
It will be shown as a diamond 






Group and Ungroup objects 




Create RF Obstacle after selecting a free draw 
Modify Any jumppad object if it is selected 
Delete any jumppad object if it is selected 
The free draw is also deleted 








Design RF Network Wizard 
Assign Channel Wizard 




Show the grid 
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1 .2.2 COVERAGE AREA DEFINITION 
Launch Points: 

• In Floor Layout using the toolbar 
(Shape) -> Insert Area 

• With that Particular Area selected 
Edit Properties 



1.2.3 NETWORK DESIGN 
Launch Points: 

Network Design can be launched only from the floor wizard 

Pagel : Allows the user to specify a set of constraints for the computation: 




Figure 3: Request/Update RF Plan 
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Page2: Shows the list of coverage Areas in the floor and allows the user to select the areas that need 
computation 




Page 3: Will show the progress of computation and upon Finish, will show all the new APs on the 
layout 




Trapeze Networks Confidential 



Page 1 1 of 40 



NMS Software design Specification 



Revision: 0.4 



1.2.4 ASSIGN CHANNELS 



This will launch a wizard which will ask the seed AP and seed Channel number to automatically assign 
channel numbers to the other APs. 
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1.3 INFORMATION MODEL 



Design Constraint 



-tead_ba)andng : boolean(id) 

-mas<_AP_DP_dstance 

use_existing_APs 

-us«_foriegnAP_ch3nneljnto 
-siniutate_singlejx3int_o7jaiJufe 
■add_APs_as_necessary 



-drffKLaflenuabon 
jhc_ filename 



Wiring Closet 



attenuaton factor : doubiefld) 

.type 



label 

dmension 

location 

proSe 

constraint 

technology 

minjtataRate 

avg_users 

avgjhruput 




OEMAP 




TrapezkAP 
















DataRateEnuro 
OataSperfkftcvrSertsiftvrtyEnurn 
■Cour»trySpeciftcTxPo>¥erEwn> 



OataRateEnum 
DataR3teSp«eaftc«cvrSensrtrvityenum 
Country SpeoflcTxPowerEnum 



1.3.1 FLOOR 

This physical view defines the floor in the building. In addition to its floor level in the building it will 
allow the user to define the following additional attributes: 

• Background image ( gif/jpg/dxf) 

• Ceiling attenuation Factor 

List of wiring closets on the floor 

• List of Access Points on the floor 

1.3.2 OBSTACLE 



Obstacles can be of many types: External wall, Internal wall, Doors, Windows, etc. 
The user can define obstacles and assign the following attributes : 
• Obstacle type 
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• attenuation Factor 

• Color 

Following Rules govern the existence of a obstacle: 

• A obstacle can be created/modified/deleted anytime. 

• The obstacles that belong to a floor will be deleted when floor is deleted. 

13.3 COVERAGE AREA 

Coverage area is a portion of the floor where the user desires a certain WLAN connectivity. An area will 
have the following attributes: 

• User -defined label 

• User - specified area 

• Technology 

• Acceptable data rate 

• Avg throughput 

• Avg. number of users 

Following rules govern the existence of an area: 

• A floor can have many areas 

• No two areas with the same technology requests can overlap 

• An area can be created/modified/deleted anytime. 

• Deletion of area will not send configuration changes to DP and/or AP. 

• An area is deleted when a floor is deleted. Deletion of area does not send configuration changes to 
the network. 

1 .3.4 DESIGN CONSTRAINTS 

To obtain a network from the planning tool, certain constraints can be provided by the network 
planner. 

• Load balancing - yes/no 
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• Define Max. AP-DP distance 

• Use Existing Access Points - yes/no 

• Default Access Point choice (for 802.1 la- AP with 1 radio, for 802.1 lb- AP with 2 radios) 

• Use Foreign Access Point Channel Information - y/n 

• Allow Addition of equipment - y/n 

• Compute coverage for single AP failure - y/n 
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2 



RF NETWORK DESIGN COMPUTATION 



2.1 PREREQUISITES 

Following are the pre-requisites that the user must specify before RF Network can be designed. 

1. Location of atleast 1 wiring closet in the building 

2. Atleast one Coverage Area defined on the floor. 

3. The coverage Area that are sharing each other are completely overlapping each other. 
The design would be done one coverage area or one set of shared coverage areas at a time. 

2.2 AP COMPUTATION 

The crux of design is to ideally place Access Points for optimal coverage based on the demands of a 
certain coverage Area. 

Based on the white paper written by the product management, the number of APs required for a certain 
area will be computed in 2 ways and the maximum of the two calculations would be the number of Acdess 
Points that jumppad would recommend for the area. For further details 

The following section covers the work-flow and the equations in detail 
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2.2.1 DEFINITIONS 




Variable 


Description j 


AP_cap 


# of AFs required based on capacity needs 


APcov 


# of APs required based on coverage needs 


N_users 


# of users 


NtotalUsers 


# of total users including the roaming factor 


ROAMFACTOR 


% of users that are going to roam in and out of the 
area 


AreaBW 


Bandwidth desired for the area 


R min 


Desired throughput (Tx and Rx) (Mbps) 


ActiveUsersPCT 


% of total users that are active at any given time 


RtotalArea 


Total access rate for the area 


Rbaseline 


Acceptable access rate for technology 
5.5, 11 Mbps for 802.11b 
36 Mbps for 802.11a 






MACEffFactor 


Ineffiicienty in MAC algorithm, Range (50-60%) 


ContentionFactor 


Additional slowdown due to the inefficieny of 
multiple users contending for bandwidth in 
CSMA/CA 


Area_cov 


Geometrical area of the Coverage Area (m A 2) 


F 


Radio frequency in GHz 


R 


AP cell radius in kms 


n 


Path Loss exponent that increases based on the 
obstacles on the floor (n =2 for free-space 
calculation) 


PLfieespace 


Path loss of Trapeze AP in free space (dBm) 
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MAXTxPower 


Country and technology specific max transmit 
power of trapezeAP (dBm) 


MAX_Rx_Sensitivity 


Data rate specific max. receiver sensitivity (dBm) 


GAFN 


Antenna gain in (dBi) 


Att_margin 


Attenuation margin allowance (-dB) 
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2.2.2 COMPUTATION OF AP_CAP 

N Jotalusers - ( 1 +ROAM%) * N_users [Eq 1 ] 

AreaBW = NjotalUsers * R_min * ActiveUsersPCT [Eq 2] 

RtotalArea = AreaBW / (MACEffFactor * ContenctionFactor) [Eq 3] 

AP cap = round (R totalArea/R baseline) [Eq 4] 



2.2.3 COMPUTATION OF AP_COV 
Algorithm 1 : 

Recursively, find the number of APs that cover the entire coverage Area by starting at the center Point 
of the coverage Area and dividing the polygon, if the ap at the center point does not cover the entire area. 

Step: 

1. Given, the shape of the polygon, confirm that it is a convex shape. 

2. If it is concave shape, it needs to be split into minimal convex shapes for this algorithm to work 
(FUTURE) 

3. Compute the maximum CELL radius ( R ) based on path loss exponent 2. This will give the 
maximum distance from the AP that the radio waves can be received. 

The cell radius can be calculated based on the following equation 

PL_freespace = 40.225 + 20Iog(f/2.45) + 201og(R) 

PLJreespace = MAX_TxPower + GAIN + (MAX_Rx_Sensitivity) + (Att_margin) 

4. Draw contour at the center point of the polygon. Note, this center point is computed by getting the 
centroid of the polygon and not by doing LxComponent.getCenter() 

5. Adjust the free space contours w.r.t obstacle databsae 

6. For 11a, check if the cell coverage is 85% sufficient. For 1 lb, check if the cell coverage is 90% 
sufficient. 

7. If it is sufficient, record this center point as one of points for placing AP and return. 

8. If is not sufficient, divide the polygon and continue with step 4. 
NOTE: do the same thing for both coverage areas, if they are shared. 
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2.3 AP PLACEMENT 

1 . Select the Max (AP__cap, APcov) as the number of APs to be placed. 

2. If the area is shared, then select the technology that needs most no. of APs as the area where APs 
need to be placed first. 

FirstArea = Area where Max (AP_a, APb), 

Second Area = Area where Min (APa, AP b) 

where AP a is Max(AP_cap_a, AP cov a) and AP b is Max (AP_cap_b, AP cov b) 

3. If AP_cov >=AP cap, use the points recorded while computing AP cov as the points where APs 
need to be placed. 

4. IF AP cap > AP cov, then compute a set of points recursively by starting at the center of the 
polygon and dividing the polygon. 

5. If the Area is not covered, use the next Tx power and go to Step 4 

6. User can move the APs or adjust the power to visually get the area covered. 

7. The user can lock the locations of the access points 

2.4 FIRST GUESS POWER 

To Compute the first guess power for APs after the APs are placed, we do the following 

1. for every vertex of the polygon, find the closest AP and raise its power (steps of 2) to see if the 
vertex is reachable 

2. For every AP, find a closest AP to its location and raise the power of each other to cover half 
the distance between them 

2.5 OPTIMAL POWER COMPUTATION 

To compute optimal power for a set of APs covering an area, we do the following: 

1 . Compute the first guess power and see if it is sufficient to cover the entire coverage area. 

2. If it is not sufficient, find the best MAX power that will cover the entire area, when this power is 
used on all APs. The range of MAJX power is from (highest of First Guess Power) to (max allowed 
for that tech and country) 

3. Once, a best max power is found, for each AP, find the best power between (its firstguess power) 
and this max power, that will not reduce the area coverage percentage. 
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To find out if a set of power is sufficient or not, we do the following 

1. Using the power, compute the contours and adjust them based on obstacle database. 

2. Find the Union of all the contours. 

3. Compute the area of the union. If it is 95% or more, this power set is assumed to be half good 

4. Compute the number of points that were not actually covered when computing the union. This 
gives us a rating of how many points were missed out because of complex geometrical union. If 
this set of points is less than 10% of the entire points in coverage area, the power set is assumed 
half good. 

5. If the power set is good in both 4 and 5, we take that power set to be good. 

2.6 DRAW CONTOUR AROUND THE ACCESS POINT 

Based on the location of AP and the cell radius, we need to draw a controur that takes into account the 
attenuation factors of obstacles around the AP 

1. Compute the cell radius, based on power of AP. If AP is not specified, compute it using the 
PL freespace. 

2. Draw a circle using AP location as the center point. 

3. Split the circle into a polygon with points sampled at every 5 degrees (72 points) 

4. For every ray that joins center point and one of 72 points, find the farthest point based on obstacle 
database 

5. Join the adusted points to complete the polygon that depicts the contour. 

2.6.1 FARTHEST POINT COMPUTATION 

Given a ray, we need to compute the farthest point for a given path loss. The goal is how far should 
one march from one point to the other to reach the given path loss with obstacles taken into consideration. 

1 . For a given ray, firnd a list of obstacles that intersect it. Note its intersection points. 

2. Sort this list of obstacles and intersection points based on its distance from pointl of the 
ray. 

3. At each intersecting point, compute the PL = PL_freespace + ^attenuation of obstacles 
that intersect till that point. 
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4. If the computed path loss is more than the passed in path loss, then use that intersection 
point as the farthest point. And return 

5. If all intersction points were processed and the path loss is still less than that passed in, 
then find the farthest point where the path loss is matched. This can be done in a binary 
sort between the last tried point to the farthest point of the ray. 



2.7 CHANNEL ASSIGNMENT 

The algorithm used for channel assignment is as follows: 

1 . channel is assigned for all radios on the floor. All Non-trapeze APs are also considered as radios 
for which channels have already been assigned. 

2. All radios are sorted by distance from (0,0) 

3. For every radio, pick an unused channel number that can be assigned. 

4. If all channel numbers are used, find out which channel number is the farthest from the radio. Use 
radios for which channel assignment has already been done. And use that channel number. To find 
the farthest channel number, sort the radios that have been assigned channels by distance from the 
radio in question. 
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3 RF VERIFICATION 



3.1 OVERVIEW 

RF Interference is a big problem in WLAN. The presence of RF obstacles within a floor can and will 
be seen on the actual coverage of devices that transmit radio signals. There is one side, where one can 
project based on some theoretical models that a coverage would look a cetain way. Thi s coverage 
^computati on is based on a lot of user inputs. The better job a user does in defining obstacles that can 
attenuate the radio signals, the more accurate the empirical models can be. However, in most of the cases, 
call it lack of interest in defining such an amount of information, or anything else, the information that is 
fed into the theoretical model is insufficient to depict the actual environment. 

Interference is not the only problem in WLAN deployment. Mis-connections and mis-configurations 
can also exist. Problems like, "A user might have planned to connect apl to port 2 , but actually it got 
connected to port 3" can be common. 

Jumppad tries to tackle these problems and provide solutions that may aid the user to better manage 
their WLAN deployments. 

RF Verification is a process that requires interactions between user and the application. It involves 
various categories - 

1 . Verify whether all APs are connected to the correct DPs as planned/coniigured. 

a. This requires not much manual intervention other than starting the verify process 

2. Verify whether a certain AP can see other APs based on propagation model chosen in Jumppad. 

a. This also requires not much manual intervention other than starting the verify process. 

3. Verify whether the coverage contours drawn by Jumppad is close enough to reality. 

a. This requires a lot of manual interaction, especially in defining the measurement points 
and providing signal strength data of all APs seen at that measurement point. The 
elements involved in this are 

L Lite application on a portable device (laptop or preferably PDA) 

ii. An API to the wireless NIC to obtain required measurement readings. ( this will 
be required to completely automate the process from the time a point is clicked 
on a certain floor map using the lite application) 

iii. Necessity of moving around the coverage area/ floor to collect such data, (there 
are many ideas of automating this step, but this is a non-goal ) 
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3.1.1 UNDERSTANDING OF REQUIREMENTS 

This section covers the understanding of Requirements for RF Verification Tool and details the design. 

• Ability to verify RF-wired topology 

• Ability for the user to move around with the tool on a portable device to gather information 

• Ability to Select a RF Measurement Point and request for projected signal strengths 

• Ability to export an existing Floor plan from jumppad 

• Ability to read in a floor plan to define RF Measurement points and RF measurements. 

• Ability to import RF Measurement readings into Jumppad 

• Ability to correct the attenuation factors of the RF Obstacles based on data collected at the 
measurement points 

Following sections do define the user scenarios for solving all the above problems, but listed here is 
the phased approach of what feature will be available in which release of jumppad 



3.1 .2 RELEASE MATRIX 



Feature 


Jumppad Release 


Comments 


Verify RF-wired topology 


1.0 


This involves 2 items: 

- DP-AP wired 
connections 
verification 

AP visibility 
verification 


Allow user to obtain projected 
signal strength readings at a given 
measurement point 


1.0 


The user can then verify this 
information, by going to that 
location and actually measuring 
the radio signals 


Allow the user to provide the 
actual readings of the signal 
strength at a given point in 
Jumppad 


1.0 


The user will have to go to the 
location of measurement point, 
measure data, and come back to 
jumppad to type in the data to 
correct coverage contours 


Provide a lite Application to 
allow the user to move around 
with the floor plan to define data 
and new measurement points 


FUTURE 
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3.1.3 ISSUES / DEPENDENCIES 

This feature has the following issues or depends on the following features: 

Jumppad support of Dual-homed AP 

- AP DTD definition 

Rogue AP Detection support in DP 



3.2 USE CASE SCENARIOS 

3.2.1 RF TOPOLOGY VERIFICATION 





Request RF Topology Verification 



get AP topology 





get Topology Information 



get unconfigured APs 



i i 
Create a summary report for the user to view 
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3.2.2 AP VISIBILITY VERIFICATION 



User 



Jumppad 



DP 



AP 



Request AP 



Visibility verification (floor, technology) 



i i 
get ap-neighbor table info (for all aps, from their seed DP) 




update AP-row information 




correct the attenuation for line of sight betn APs 



It is assumed that the data is already collected with regards to ap-neighbors 
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3.23 RF COVERAGE VERIFICATION 




Export a floor plan 




Jumppad Lite 




Save the "Floor" plan + graph in the specified directory 



Open a Plan and import the floor plan 
t 



Define/Edit RF Measurement Point 



Enter RF Measurements 



Export the floor plan 



Save the floor plan in specified directory 



Import the floor plan ( will override the floor graph ) 



Edit the floor plan and request for RF verification 




Apply correction to RF Obstacles based on the data 



Re-draw contours, if enabled to show the correction 
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3.3 RF TOPOLOGY VERIFICATION DESIGN (RFTOPO VERIFIER) 



3.3.1 USER INTERFACE 

The intent here is to show the differences between what the DPs are configured for a given AP and 
what AP sees from the DP. 



3.3. 1 A Launch Points 

Changes -> Verify AP Topology 



3.3.L2 APTopoVerifierWizard 
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The wizard will have only one page as shown above. Following UI rules will apply on the page: 

1 . Verification can be done only per mobility domain 

2. Once Verify is clicked, all other buttons are disabled and status bar will indicate that information 
is being obtained. 

3. Jumppad will construct one big request per device with i individual request per Port to get topology 
status on the port. 



4. Jumppad will receive the information, try to make sense out of it and show the information in a 
table. 

5. Edit button will be enabled only if one of the rows is selected. When a row is selected, some 
helpful hint will be provided to indicate what might have happened and how to fix it. Using Edit 
button, user can edit the Access Point (note, this wil be a dual-homed object) to fix the error. 
Editing the object does not mean that the error is fixed from the network. A next deploy will 
supposedly fix the error. 

6. Finish / Cancel will be enabled once Verification is complete. 

7. A Cancel would discard all edits that were performed on the access point to fix it. 

8. There will be some errors on access points that do not exist in jumppad at all. In such case, Edit 
will be disabled for such errors. This is possible in the case when the AP was not configured in 
jumppad, but was auto-discovered by DP and the configuration is out-of-sync. IBSffiS^H 



33.2 WORKFLOW 

Following are the steps that jumppad will take to verify the RF wired topology: 

1 . Request the AP topology information from Devicelnterface 

2. DeviceManager will send out requests to each of the DPs that are currently being managed by 
jumppad 

3. DeviceManager will also send out request to obtain list of all unconfigured APs that are requesting 
the boot image. 

4. The RFTopoVerififier will collect a list of errors on APs that have one of the following errors: 

a. AP product type misconflguration 

i. AP is configured to be one type, but it is actually of another type (Note: this is in 
the case when user has created AP in jumppad) 

b. Radio Slot misconflguration 

i. AP is configured to the right type, but the slotl contains Radio B instead of 
RadioA 
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c. Primary DP misconfiguration 

i. AP is configured to be connected to DPI as primary ( with higher BIAS), but it 
is actually connected to DP2 

ii. AP is configured to the right DP, but the bias value received from the AP for 
that DP is not the same. 

iii. AP is configured for the right DP, but the cluster member IP address of the DP 
is different. 

d. Secondary DP misconfiguration 

i. AP is configured to be connected to DPI as secondary ( with lower BIAS), but it 
is actually connected to DP2 

ii. AP is configured to the right DP, but the bias value received from the AP for 
that DP is not the same. 

iii. AP is configured to right DP, but the cluster member IP address of the DP is 
dfferent. 

e. Primary DP Port misconnection 

i. AP is configured to right AP, but it is connected on the wrong port 

f. Secondary DP Port misconnection 

i. AP is configured to right AP, but it is connected on the wrong port 

g. Unconfigured AP in DP 

i. AP does not exist in jumppad and this DP is getting boot image requests 

ii. AP exists in jumppad and is connected to DP2, but DPI is getting is boot 
requests (Q.. will this be caught by e?) 



3.3.3 ISSUES 



6. Since any request to a device will fail if the generation count has a mismatch, it 
emphasizes that all devices are In-sync in jumppad. 

7. It is not desirable to use the syslog for this information as it can take a lot of time in 
processing the information. 



3.3.4 INFORMATION MODEL 
Required Information From DP: 
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1 . AP Topology information Status 

a. Topology information as created using the announce packet information of AP or the 
complete topological information from the AP. The information required is: 



DP 


IP address 


DP Port 
Number 
Connected 
To 


DP Bias Value as 
seen by AP 


DP status as seen by AP 


Primary DP 


Cluster mbr ip 


1..20 


H/L 


Up / Down 


Secondary DP 


Cluster mbr ip 


L.20 


H/L 


Up/ Down 



Q: if AP can already say which one is Primary, is the bias information not already available that 



way? Ie. Does AP not make a DP primary based on bias value? 

33.4,1 APTopologyStatus 

• Internally generated key and transient object 

• Not linked to any object in model (similar to AbstractStats Object) 

• Has a key information of the associated object (in this case TrapezeAP) 

• Contains the topological information that is being received from AP. 
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3.3.5 CLASS DIAGRAM 



AbstreCtRTimg 



7Y 



TmpgzeAP 



AbstractApplAction 



APTQpo|ogy$tatu? 



VeriftyRFTopologyAction 



Trapeze Networks Confidential 



Page 32 of 40 



NMS Software design Specification 



Revision: 0.4 



3.4 AP VISIBILITY VERIFICATION DESIGN (A PNE I GHBOR VERIFIER) 

3.4.1 USER INTERFACE 

The intent here is to show what an AP sees over the air. The information will have two views, one 
tabular, similar to a dashboard, the other viewing the errors on the graph of the selected floor. 

The scope of the information that will be retrieved and shown will depend on a selection of a Floor 
and the right technology. 

3.4.1:1 Launch Points 

Changes -> Verify AP Visibility 
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3.4.1.2 APVisibilityVerifierWizard 



wwmmmmmw& % wmrnm mrnmMmmmmmmmsm 



Select Floor Ifioom 



Technology ® 802 113 C ao2.nb 




1 . AP visibility verification can be done only on a per floor and technology basis 




3. The status column can have one of the following messages: 
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a. Scheduled 

b. Collecting Data 

c. OK 

d. Communication Failure 

4. Once each AP sends back information, while other AP is being requested for the same 
information, Jumppad will populate the above shown grid as to who is available with what signal 
strength. (We can use the tool tip to show the signal strength, if showing a number on the signal 
does not look good) 

5. The legend will be as follows: 

a. Configured Value (Green) 

b. Actual Value (Red) 

c. Not applicable (Grey) 

6. Status / List box will indicate any rogue APs that were discovered. This will however not give the 
user option to create the rogue AP. It is a non-goal of this feature. It is possible that the neighbor 
list also reports managed APs that are in a different floor. 

7. In the graph Layout, the user will be able to graphically see where the errors are located. Using the 
BSSID information and the signal strengths received from its perceived neighbors, jumppad will 
attempt to approximate the location of the AP.(TBD) 

3.4.2 INFORMATION MODEL 

3. 4. 2. 1 Required Information from DP 

A table of neighbors that a particular AP sees with the following information about each neighbor: 
-BSSID 

- channel number 

- technology 

- Signal Strength 

- Signal to Noise Ratio 

3.4.2.2 APNeighborsStatus 

• internally generated key 

• Models the table sent from DP with regards to AP neighbors 
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• has a ObjectKey of the associated AP 

3.4.3 WORK FLOW 

Following are the steps that jurnppad will take to verify the RF wired topology: 

1 . User requests to verify AP visibility 

* 2. Jurnppad requests neighbor AP information from each of the AP 

3. Jurnppad creates g report to show the (hiYerence between and actual 



visibility j 






Trapeze Networks Confidential 



Page 36 of 40 



NMS Software design Specification 



Revision: 0.4 



3.4.4 CLASS DIAGRAM 



AbstractRTime 



AbstractApplAction 




Tra peze AP 



Verify APVisibilityAction 
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3.5 RF COVERAGE VERIFICATION DESIGN (RFCOVERAGEVER1FIER) 

3.5.1 USER INTERFACE 
Launch Points: 
From within Floor Wizard 
Wizard: 

RFMeasurementWizard 
Pages: 



MeasurementPointsSelectPage ( to select the points that u need to apply on the AP 
coverage ) 

M easurementEntryPage 



Note: do we want to show the user the obstacles whose attenuation factors were corrected? 

3.5.2 INFORMATION MODEL 

3.5.3 WORKFLOW 



1 . the user will export the floor plan from jumppad. 

2. jumppad will export the "Floor" information in XML similar to device mode with all non- 
deployable information. 

3. Jumppad will export the jlx file to the specified directory. 

4. Jumppad has now created the files required to move around with the floor plan 

3. 5. 3. 2 User runs Jumppad-Lite and loads the floor plan 

1 . User launches jumppad-Iite and opens a new plan 

2. User imports the "Floor" into the plan. Both files must exist in the specified directory. 

3. User can now launch the floor wizard by editing the floor plan 

4. User can create new RF measurement points or edit existing measurement points 



3.5.3, 



1 User needs to move around with the floor plan 
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3.5.3 .3 User Wishes to enter RF measurements being received by the portable 
computer 

1 . User edits the floor wizard, if a measurement point is to be created. 

2. User selects a RF measurement point and launches RFMeasurementWizard to enter the data. 

3. User will enter the following based on the information: This information is for the best signal 
being received. This measurement must be entered for the AP that the user is connected to.) 

a. Technology (802.1 la or 802.11b) 

b. BSSID of the AP 




c. Signal strength 

d. Frequency of the received signal 



4. User then moves to the next measurement point and follows the same procedure. 

5. User can create more measurement points, if needed. 

" * ™ "SHU 



3.5. 3.4 User is done entering RF measurements and now wants to verify coverage 

1. User will export the "Floor" from Jumppad-lite. It will create two files, "Floor" information 
XML and the JLX file. 



3. 
4. 



in 



User will import this "Floor" information onto existing floor in Jumppad. Jumppad will read in 
the edited jlx file and also apply changes to "Floor" object. ( we now have all the measurements 

User then launches RfCoverage Wizard to verify the RF coverage. 

User selects the RF measurement points that need be applied to correction of RF coverage ( 
default would be all selected ) Only those RF measurem»olnMhat haVe been rec^i#ll 



or have a unappiiedxorrection to attehualibri f 



nation .fact(ir;^ will bc sbo^rhere. 



Jumppad will compute the correction factors on obstacles based on the signal readings. If there 
is no obstacle defined and there exists a correction factor it will create a new obstacle close to 
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the measurement point and assign that correction factor. Once, the correction factor is applied, 
the information on the RF measurement point will be nullified. 

Jumppad uses the information obtained from RF neighbors to correct the line of sight from two 
given APs. 

User may accept all corrections/changes to view the corrected contours for a given area 



3.5.4 CLASS DIAGRAM 



Coming soon.... 
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1 INTRODUCTION 

1.1 GOALS AND SCOPE 

The goal of this document is provide a functional specification of the additional features and functions for 
RingMaster 1.1. 

1.2 OVERVIEW 

RingMaster VI .1 is a minor update to the field that includes the following high-level features: 

• HP OpenView Integration 

• Solaris OS Support 

• MSS 1.1 Support 

o WPA 

o 11G Support 

o Boot/Upgrade changes 

■ Not yet understood if this impacts RM or not 
o Mobility ACLs 

■ Not yet understood the full impact of these changes 

In addition to these new features, RingMaster functionality will also be changed in the following areas: 

• Transaction Management 

- To improve scalability and performance (i.e. MROW) 

• Versioning 

- Fundamental to support 1 .0 and 1 . 1 MSS versions at the same time in RingMaster. 

• Additional Rules 

Including some new rules we missed or deferred in 1 .0 

• Bug Fixes deferred from 1 .0 or found in FCS version of RingMaster 
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2 802.1 1 G SUPPORT 



802.1 lg is a RF technology that works on the same frequency band as 802.1 lb. it is similar to 802. lib 
in channel numbers allowed for the technology. It uses a different modulation to provide the high over-the- 
air data rate. It is possible for a 802.1 lg radio accept 802.11b client. This degrades the 802 lie 
performance. 



2.1.1 INFORMATION MODEL 

2.1.1.1 RADIO 

Radio Type: A radio can be of the types 802.1 lb, 802.1 la, and 802.1 lg. 
Channel Numbers: 

802.1 lg uses the same channel set as 802.11b. However, it is possible for some countries not to 
support it. 

Transmit Power: 

From the regulatory domain point-of-view, 802.1 lg can use powers similar to 802.1 lb. The variation 
of transmit power for a 802.1 lg radio will depend entirely on the chip-set used. This information will also 
be product management. 



Action Item: (Product Management): To provide Country specific information with related 
to 802.1 lg support 
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2. LI. 2 RADIO PROFILE 

Force 1 lg only: This attribute is required for 1 Ig radio to allow / restrict lib clients. When checked, it 
will be in "pureG" mode and when unchecked, it will be in "mixedBG" mode. When in mixedBG mode, 
the radio can accept 1 lb clients and also listen to 1 lb beacons. 




2 J. 1.3 MP-MODELS 



The following new models will be available to support 802.1 lg. the actual model number cannot 
be specified as yet. 



• Single-radio-802. 1 1 (a, b, g)-only (In this document, refered to as MP-24 1) 

• DuaI-radio-802.1 l(a, b/g) (In this document, refered to as MP-252) since the BG radio can be 
soft configured as 1 lb or 1 lg, the radio type attribute will qualify this information. 

With the possible introduction of these two modules, RingMaster will allow possible MP models 



MP Model 


MP type 


Radio Type (MP subtype) 


MP- 122 


MP-122 


None 
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MP-101 


MP-101 


11a or lib 


MP-241 


MP-241 


1 la or 1 lg 


MP-252 


MP-252 


None 



2. 1.1.4 RECEIVER SENSITIVITY: 



The receiver sensitivity of the radio in 802.1 1 g will not be the same as 802.1 lb due to the variation in 
possible data rates. The sensitivity for llg radio is shown in the following table. As a comparison, the 
same for 1 lb/1 1 a are also shown. 



Data Rate (Mb/s) 


802.1 la 


802.1 lb 


802 Hp 


] 




-92 




2 




-90 




5.5 




-89 




6 


-88 




-88 


9 


-86 




-86 


11 




-87 




12 


-85 




-85 


18 


-83 




-83 


24 


-80 




-80 


36 


-76 




-76 


48 


-71 




-71 


54 


-70 




-70 



2.1.1.5 DESIGN CONSTRAINTS 

There is a design constrant that the user is allowed to select:- Default MP Choice. Currently, it has 
choices of MP models. With the introduction of 1 lg, it is no longer the entire floor option as all models do 
not fit all combinations of technologies. Therefore, this constraint will become an attribute on Coverage 
Area and will also be allowed to change in 2 nd page (coverage Area selection) of Compute and Place 
wizard. 

The choices that will be available for coverage areas are as follows: 
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Area technology 


Choices 


Default Choice 




1 la, unshared 


All choices 


MP-241 


1 lb, unshared 


All choices 


MP-241 


1 lg, unshared 


New models only 


MP-241 




1 la and 1 lb, shared 


Dual Radio models only 


MP-252 




1 la and 11 g, shared 


New dual-radio model only 


MP-252 ^ 



The 2° page in compute and place operation will look as follows: 
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2.1.1.6 COVERAGE AREA 

When creating a coverage area, the user can choose from the following in addition to the existing 
choices: 

802. 11 g only 
- 802.11a and 802. 11 g 

Coverage Area will have an additional attribute to allow/disallow 802.11b clients. This information 
will be rippled to all the associated 1 lg radios in the coverage area. 

ForceG: This attribute will be provided to allow the user to force 1 lg mode on the radios associated 
with a 1 ]g coverage area. This attribute will be enabled and visible only for 1 lg coverage area. 

Radio Profile: the user will be able to choose a radio profile that will be applicable to all the radios of 
the given coverage area. If the selected radio profile is not found in the configuration of the device of any 
radio, the radio profile configuration is applied to that device. 

i. The list of radio profiles that will be available will depend on the mobility domain associated 
with the coverage area. It will show all the radio profiles that are policies 

ii. The user will be able to create a new radio profile policy from the area wizard. 

iii. Any changes to the radio profile property will apply to all radios associated to the coverage 
area when the modify wizard is finished. 
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2.1. 1.7 RF OBSTACLES 

The Attenuation factor of an RF obstacle is same in 1 lb and 1 lg as they share the frequency band. The 
Label of the attenuation factor will reflect the same. 



2.1.1.8 CHANNEL SET 

Similar to 1 lb, 1 lg needs a channel set selection at the network plan level. However, since they share 
the same frequency band, the selection of the channel set must be same for 1 lb and 1 lg. Hence, the label 
will reflect that this channel set is for both 1 lb and 1 lg. 



2.1.2 MP COUNT COMPUTATION 

As 802.1 lg radio can accept 802.11b clients, it becomes critical in MP count computation based on 
capacity that this behavior is known. This behavior also depends on the final chip-set that is selected. Going 
on the assumption that this is possible, this information should be known before capacity based 
computation is performed. 

Here are the values of some constants used in the computation logic: 



Constant or Attribute 


11a 


lib 




Loss Margin 


5dB 


lOdB 


5dB 


Baseline association rate 


36 Mbps 


11 Mbps 


24 Mbps 


Minimum transmit 


18 Mbps 


5.5 Mbps 


12 Mbps 


Baseline association rate for llg in 
mixedBG mode 






Will not be more J J 
Mbps 


Minimum transmit rate for llg in 
mixedBG mode 






Will not be more 5.5 
Mbps 











Action Item: (Product Management) to provide the defaults of baseline association rate for llg. 

This behavior does not impact the coverage based computation as in the empirical model the 
frequency for both 802.11b and 802.11g is the same. All llg constants will be used for computation 
Therefore, the maximum receiver sensitivity will be used based on the association rate specified. 



2.1.3 MP PLACEMENT COMPUTATION 

There is no impact to the placement of MPs with introduction of 802.1 lg 
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2. 1 .4 OPTIMAL POWER COMPUTATION 

There is no impact to optimal power computation of MPs with introduction of 802.1 Ig. 

2.1.5 CHANNEL ASSIGNMENT 



floor, 



1 lg uses the same channel numbers as 1 lb. So, when channel assignment is performed for the entire 
, all lib and llg radios will be considered together to reduce co-channel interference. The U] will 



show all the 1 lg radios in the current 1 lb page. 



Sjchannel Assignment 




2.1.6 RF COVERAGE 

be sitz~tinr coverase for a 1 ,s radio ' a user must spedfy if the c ° ntour is needed <o 

There will be an additional option in the pop-up menu on MP to view llg RF coverage If a coveraee 
area .s selected, ,t will draw RF coverage for the technology of the coverage area. § 

radioTn 1 lb"/! fg C0Vera8e " SeIeCted ' ^ ^ ™ Y ^ 10 ^ COVera 8 e for » ts associ ^ 

2.1.7 RF MEASUREMENT MONITORING MODE 
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2.1.8 RF MEASUREMENT POINT MODIFY WIZARD 

Similar to reasoning mentioned in the above section, in the modify wizard of a RF Measurement point, 
the technology option of 1 lb will be changed to 1 lb/g. 
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2.1.9 WORK ORDER CHANGES 

Wherever the coverage Area (802.1 lb) is shown, it will now show "Coverage Area (802.1 lb/g)" As 
an example of the work order snippet table for an MP location: 



IS 



2.1.9.1 . LOCATION OF MP-QE-3 



Model 


MX Port 
(Name:Port) 


MX Port 
(Name:Port^ 


Coverage Area 
(802.11a} 


Coverage Area 
(802.116/0^ 


MP- 

252 


MX284:P03 




Area_a 


Area_g 



Also, the RSSI readings of 1 lb and I- lg radios will be shown in one table in all the places in the work 
order. 
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2.1.10 FLOOR VIEW 

A new icon will be added to view the RF coverage of 802.1 lg areas or radios. An option in the pop-up 
will be added to view the 1 1 g RF coverage 

In the read-only view, the 1 lg-icon will draw RF coverage for a 1 lg radio in "pureCmode. And 1 1 fa- 
lcon can be used on a I lg radio to view the RF coverage in "mixedBG" mode. 

2.1.11 VERIFICATION RULES 

1. Rule to verify that all 1 lg radios associated with one coverage area are in the same mode of 
"pureG" or "mixedBG" 

2. Rule to verify that the 1 1 g radios associated with a coverage area belong to 1 . 1 running MX. 

3. Rule to verify that the selected Radio profile for a coverage area is the same for the associated 
radios 

4. Rule to verify if the selected MP type is supported in the version of MX that is being deployed 
to. 

5. Rule to verify the following on a coverage area: 

a. If Coverage Area is for 1 lg and has been forced to use 1 lg mode, the associated radio 
profile needs to specify a mode to match the same. 

b. If Coverage Area is for 1 lg, the associated radio profile needs to specify a mode that is 
NOT "lib only" 

c. If Coverage Area is for 1 lb, the associated radio profile needs to specify a mode that is 
NOT "llg only" 

2.1.12 RF DETECTION AND DISPLAY OF ROGUES/KNOWN DEVICE 

With the introduction of 1 lg, RF detection module needs updates to do the following 
allow user to exclude 1 lg radios 
view 1 1 g discovered devices 
view 1 1 g known devices 

- Locate a 1 lb transmitter, where one 1 lg is a potential listener. A 1 Ig can listen to 1 lb only when 
it is in "mixedBG" mode 



2.1.13 CLIENT LOCATION 

With the introduct.on of 1 lg, client location module needs updates to handle an 1 lb client beine seen 
by a 1 lg radio. 6 
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2.1.14 NETWORK TOPOLOGY VERIFICATION 

With the introduction of Jig, verification of network topology, possibly, needs updates to the new 
model types and new radio type. 



2.1.15 CL1 MAPPING/DTD CHANGES 

There will be a need to correct the CLI mappings for some commands that will have additional 
attributes or values. 

Action Item: (Product Management) to provide CLI commands changes to incorporate llg. 
Action Item: (Engineering) to decide on DTD changes to incorporate llg 



2.1.16 STATISTICS 

There will be additional fields in radio statistics with introduction of llg. Because of this, the radio 
statistics display will need updates 

Action Item: (MP team) to provide additional fields in radio statistics 



2.1.17 IMPACT OF MX VERSIONING 

Certain CLI commands or attribute value pairs will not be available for certain versions of MX 
software. This will impact various planning operations. 

1 . The user will be able to change the MP type irrespective of the version of MX it is connected to. A 
verification rule will catch any unsupported mp type errors. 

2. Planning tool will create new MX for llg, if there are no 1.1 MXs in the wiring closet with free 
ports for MPs. 

3. Any 1.0 MX that is uploaded in a network plan for a country-code that is not allowed in 1.0 will 
be marked as ready to be upgraded to 1.1. This can happen as country code is an optional 
configuration in basic setting of the box. Note: RingMaster must let the user know if there is no 
1.1 image present for upgrade to such box, upon next deploy. An example of the work flow will 



be: 



a. 



user creates a network plan for the new country code 



b. 



User uploads an MX that is running 1 .0 image 



c. 



Ringmaster wll accept the configuration from that box and 



i. Change the country code to that of the plan 



ii. Mark the mx for "image and config" upgrade during the next deployment 



d. 



Upon next deployment, the user will be prompted if there is no 1.1 image present in the 
image repository 
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2.1.18 NON-GOAL 

11 g introduces a mechanism in which a radio can go into "protection" mode to further reduce the 
throughput. This normally happens when in 1 lg- environment, a 1 lb devices are nearby. 

Although, MP radio can provide such information in its status, if the radio has gone into protection 
mode or not, there is currently no requirement in RingMaster to display this information. 
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3 CONCAVE SHAPE SUPPORT 



In current implementation of RingM aster, planning tool was unable to handle concave shapes. Also, 
the shared areas were said to be exactly overlapping each other. Here, we try to solve both of these issues to 
make the planning tool less restrictive. 



The support of this feature will be able to handle the following 



• Concave shaped coverage areas 

• Shared coverage areas to use shared MPs only in the overlapped areas 

A concave shape is one where any internal angle of the shape is greater than 1 80 degrees. The user will 
be able to draw this kind of shape and the planning tool will be able to handle coverage based computation 
and placement of the APs. 



Some examples of concave shares are as follows: 




Caution will still have to be taken as to how many such concave angles are provided in the coverage 
area that is drawn. As an example, if the floor plan does look like the one shown below, a triangular 
coverage area might end up giving a better result. Geometrically, planning tool will be able to handle any 
shape, however, more complex concave shapes might end up in slow performance and high number of AP 
count. 



This restriction might not exist by the time this functionality is implemented. But, it is brought out here 
as possible caution point for planners. 



Trapeze Networks Confidential 



Page 18 of 47 



Ringmaster i.l Functional Specification 



Revision: 0.10 



3.1.1 DECOMPOSITION OF A CONCAVE SHAPE 

An appropriate algorithm will be chosen to solve this issue. 

3. 1 .2 SHARED COVERAGE AREAS 

The user will be able to share MPs across coverage areas that are not completely overlapping each 
other. As an example, the user will be able to draw the following two coverage areas and then mark it 
shared. The planning tool will share the MPs only in the overlapped area and compute and place MPs in the 
unshred area based on the constraints. 



Areal 














Area2 



The scope of shared areas still stands as follows: 

No two Coverage areas of the same technology can be shared 
Coverage area for 1 lb and 1 lg cannot share MPs 

When placing APs in shared areas, all APs are assumed to be dual-radios 

Any dual-radio mp that belongs to each coverage area and is not locked is a potential candidate to 
be placed in the shared area. 

In addition to the above constraints, following additional rules will apply: 

- If the shared area is 90% or more overlapped, then the planning tool will assume the entire area to 
be overlapped and use the coverage area for 1 la as the basis. 

- If one coverage area is completely inside the other coverage area, they will not be considered as 
shared areas. An example is shown in the following picture. 

Areal 

Area2 
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4 MOBILITY ACL SUPPORT 



Needs to be defined what this requires. 
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WPA SUPPORT 



Wi-Fi Protected Access is a specification of standards-based, interoperable security enhancements that 
strongly increase the level of data protection and access control for existing and future wireless LAN 
systems. 

Currently, the securirty mode is assumed to be Legacy WEP and the authentication mode is assumed to 
be 802.1X. In addition, the user may define WEP keys 1 ...4 at the Radio Profile. Such configuration is 
apploed to all radios associated with that radio profile. 

Enhancing on the same lines, the following additional choices will be available on a Radio Profile. 

5.1.1 INFORMATION MODEL 

Following security modes will be supported by future releases of MX and MP. Each security mode has 
certain constraints on the following types of information 

1 . Authentication mode (Multi-select) 

a. 802. IX 

b. PSK (Pre-Shared Key) 

2. Encryption mode: (Multi-select) 

a. TKIP 

b. AES 

3. Keys 

a. 4 40-bit or 128-bit Keys for WEP 

b. 1 63-charKeyforPSK. 

Note: PSK may be defined per MAC-user as well. However, it is not yet decided what route of PSK 
will be allowed in Trapeze mobility system. 

4. Counter Measure Time 

a. the counter measures are spawned when the Message Integrity 
Check ("MIC") is triggered under conditions defined by the WPA 
specification. Default: 60 seconds. 



5.1.1.! LEGACY WEP 



This will be supported for backward compatibility. It is similar to what exists in release 1.0. The user 
may choose to specify 40bit or I28bit WEP keys. A total of 4 WEP keys may be defined. 
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The authentication mode is always 802. IX. Hence, this information is not available for the user to 
modify 

5.7.7.2 WPA ONLY 

This type of security mode involves the following: 
Allows any combinations of Authentication modes 
Allows any combination of Encryption modes 

If the Authentication mode is PSK, the user may specify a key using the allowed valid characters 
No WEP keys need be defined. 

5.7.7.5 LEGACY WEP + WPA 

This type of security mode allows clients that talk Legacy WEP or WPA. This involves the following: 
Allows any combination of Authentication modes. This is applicable to WPA only 
Allows any combination of Encryption modes. This ia applicable to WPA only 

- A PSK key may be defined if PSK is selected. 

Upto 4 WEP keys may be defined for use of Legacy WEP. 

5.1.2 USER INTERFACE 

The UI screen will look something like this on the Encryption page when editing a Radio Profile 
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Modify Radio Profile 




Summary of Modes: 



Mode 


Authentication 


Encryption 


Keys 


WEP 


802. lx checked and 
disabled 

PSK disabled 


TKIP and AES 
disabled 


WEP Key 1.. 4 enabled 
Pre-shared Key disabled 


WPA 


Both enabled, by 
default, only 802. IX 
checked 


TKIP and AES 
enabled, none 
checked by default 


WEP Keyl..4 disabled 

Pre-shared Key enabled, only if PSK 
is checked 


WPA + WEP 


Both enabled, by 
default, only 802. IX 
checked 


TKIP and AES 
enabled, none 
checked by default 


All keys enabled, PSK is enabled only 
if PSK is checked 
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5.1.3 FAULT/ EVENTS LOGGING 

Useful information that may be obtained from the radio w.r.t. the security is when the radio has gone 
into performing counter measures. This normally happens when the radio has been hacked into. What the 
radio does is disassociate all clients and not associate any client for a period of time that can be configured. 

It is suggested that a trap be defined in the MX that may be received by NMS monitoring applications, 
like HP Openview. 

Action Item: (MX Team) to confirm if there is an addition of a FACILITY with introduction of 
WPA. 

If the above action item results in an additional Facility, RingMaster will have minor changes to the 
preference panel. 



5.1.4 STATISTICS 

New statistics will be defined when WPA is implemented. Currently, no new statistics are defined. If 
new statistics are implemented, there will be certain changes to Radio based statistics. 

Action Item: (MP team) to define new statistics for WPA, if applicable 

5.1.5 VERIFICATION RULES 

1 A Rule to verify that if an Authentication mode of PSK is selected, a non-empty PSK key is 
specified. 

5.1.6 CLI MAPPING / DTD CHANGES 

New commands will be added and this will require mapping to show changes in RingMaster 

Action Item: (Product Management) to provide new CLI commands 

Action Item: (Engineering) to decide on DTD Syntax to exchange this configuration 

5.1.7 IMPACT OF MX VERSIONING 

Certain CLI commands or attribute value pairs will not be available for certain versions of MX 
software. 
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6 



SOLARIS OS SUPPORT 



The Solaris Operating System requires the installer to be updated to handle installation as well as other 
environment updates. 

The default location for RingMaster on Solans will be: /opt/trpz/ringmaster 

The sub-directory structure under the install directory will be the same as Windows. 

All user and system preferences are stored [to be figured out where they go but it will be 
significant] 

(more flushing out required] 
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7 



HP OPENVIEYV INTEGRATION 



7.1 OVERVIEW 

Here is a brief list of features that will be implemented in Release 1.1: 

• Installation of integration files 

• Menu and Toolbar Integration 

• Symbol Integration 

7.2 INSTALLATION OF INTEGRATION FILES 

There will be a separate installer to install NNM integration files. At the end of RingMaster installation 
user will be prompted whether he would like to install NNM integration module. User can proceed with 
NNM integration installation or come back at a later time and run this installation. RingMaster has no pre- 
requisite of NNM to be installed before it can be installed. 

Pre-requisite to run NNM integration installer 

• Need to have installed NNM 6.4 or later version 

• Need to have admin privilege to run the installer 

• OS supported - Windows XP, Windows 2000, Solaris 8 and 9 on SPARC (No x86 support 
running Solaris) 

During installation installer will try to get the path for NNM from OV_MAIN_PATH environment variable 
and will prompt to the user to confirm or provide the right location. User will also be asked to enter default 
plan name that need to be used when RingMaster is launched from NNM. This plan name is inserted as an 
argument in the places where RingMaster is invoked in the application registration file. User needs to edit 
the registration file if he wants use a different plan. 




Following files will be installed 



Application Registration File 



o UNIX - /etc/opt/OV/share/registration/$LANG 



o Windows - instaIl_dir\regisrration\%LANG% 
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• Symbol Registration File 

o UNIX - /etc/opt/OV/share/symboIs/$LANG 
o Windows - install_dir\symbols\%LANG% 

• Bitmap for the switch 

o UNIX - /etc/opt/OV/share/bitmaps/$LANG 
o Windows - install_dir\bitmaps\%LANG% 

• MIB Files (Not sure of the exact location on UNIX) 

o UNlX>/etc/opt/OV/snmp_mibs 
o Windows - install_dir\snmp_rnibs 
Following files need to be modified during installation 

• HPoidtosym - This file provide applications with a mapping from sysObjectID to default 
symbol class and type. 

o UNIX - /etc/opt/O V/conf/oid_to_sym 

o Windows - install_dir\conftoid_to_sym 

• ovw fields - This file contains vendor specific information 

o UNIX - $OV-FIELDS/c 

o Windows - install_dir\fields\c 

• snmp_fields - This file contains SNMP agent information 

o UNIX - $OV-FIELDS/c 

o Windows - install_dir\fields\c 

• Oidtotype - This file provides NNM with mapping from sysObjectID to default object type 

o UNIX - etc/optOV/conf 
o Windows - install_dir\conf 

Once above files are updated following commands need to run to make changes effective. Following 
commands need to be run at the end of installation only if NNM is running. Before running following 
command we need to convey to the user, for the integration to take place NNM need to be re-launched and 
get a confirmation whether he wants installation to restart NNM. 

Issue: How do we find out whether NNM is running? 
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ovw -fields 
exit ovw 
ovstop netmon 

ovtopofix -u -o <sysObjectID> 

ovstart netmon 

ovw 

• If installation fails for any reason all the changes done during installation should be reverted back 
to original state. 

• At the end of installation PATH environment variable need to update with RingMaster 
executable's directory so that NNM will not have any problem launching RingMaster. 

• After successful installation if user runs installation again old files should be overwritten and 
duplicate entries should not be created in the files that are modified during installation. 

• During RingMaster installation there is no pre-requisite for NNM to be installed. 

7.3 UNINSTALL 

• There will be separate uninstall program that user can run anytime to uninstall NNM integration 
components. 

• During uninstall of RingMaster user will be prompted whether he wants to uninstall NNM 
integration files. Upon user confirmation NNM integration uninstall will be launched to remove 
all the files that were copied for NNM integration. 

7.4 MENU AND TOOLBAR INTEGRATION 

Menu and Toolbar integration is done using Application registration file. This registration file is 
copied to proper place during installation of NNM support. This file is loaded by NNM and parsed when 
NNM is started. When NNM begins initialization, it searches in various pre-defined directories for 
registration files. For every application of symbol type registration file found, NNM opens and parses for 
correctness. If the entry is valid then NNM performs appropriate operation (for example, adding a menu 
item in NNM menu structure or adding a button to the toolbar. . .etc). 



7.4. 1 TOOLBAR INTEGRATION 

There will be a toolbar button to easily launch RingMaster for NNM. Clicking on this burton launches 
a new instance of RingMaster if there is no instance running. To support this integration on UNIX a 
pixmap of 24 pixels need to be stored in $OV-BITMAPS/$LANG/toolbar and for windows a bitmap of 16 
pixels need to stored in install_dir\bitmaps\$LANG\tooIbar directory. 

When RingMaster is launched from NNM we can open a default plan. This plan name can be an 
environment variable or stored as a part of system preference. If a default plan is not provided then user is 
given an option to create a new plan or open an existing plan. 
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7.4.2 MENU INTEGRATION 

There will be a menu item under Tools menu to launch RingMaster or specific sub functionality (Event 
Viewer, RF Detection... etc) of RingMaster from NNM. When sub functionality is selected then 
RingMaster is launched first then selected sub functionality window is shown. Selecting sub functionality 
menu item from NNM has no effect if there is an instance of RingMaster running. There can be only one 
instance of RingMaster mnning at any time. 




7.5 SYMBOL INTEGRATION 



Symbols are graphical representation of objects in NNM. Symbols can either be icon or connection 
symbols. Icon symbols represent network or system management elements while connection symbols 
represent connection between elements. 



We will be supporting only icon symbols. These symbols will represent MX. Symbol integration is 
done using symbol integration files. Each symbol is identified by its symbol type. Symbol type is defined 
by a symbol class/subclass pair. Symbol class defines the symbol category while subclass defines a 
particular element within that class. 

7.6 COMMAND LINE SUPPORT IN RINGMASTER 

RingMaster need to support command line arguments that are passed when it is launched from NNM. 
One of the arguments that are passed to RingMaster from NNM is default plan name that needs to be 
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shown when RingMaster comes up. Other argument could be sub functionality that needs to be shown 
after opening the plan. 

We can use following command line flags to identify the arguments passed 

• -plan <planName> : -plan flag indicates that following argument is the name of the plan that 
needs to be opened [if name is empty or null don't open the plan] 

• -function <sub functionality> : -function flag indicates that following argument is the sub 
functionality that needs to be launched after opening the plan. 

• Valid sub functionality values are : 

o 1 - Event Viewer 

o 2 - User Management 

o 3 - RF Detection 

o 4 - RF Verification 
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8 TRANSACTION MANAGEMENT 



The application contains multiple background managers that require access to model data. But, these 
background managers cannot safely use the TxnConrroller as an wizard/action may be in progress. With the 
current TxnConrroller design, even the act of parsing XML from an external source while another operation 
is in progress, can corrupt the state of the model. And, for time critical data like statistics and status waiting 
for the wizard/action to complete is not an option. 

To work around this design deficiency background managers have attempted to use their own 
TxnConrroller. This scheme works for parsing simple data, but falls apart when references and other 
relations need to be built as the parsing fails if the relation cannot be consummated. A temporary patch to 
solve this was to cache any needed objects in the background managers TxnConrroller. This caching is 
quite expensive as a large part of the model is being replicated in the background manager (consider status 
collection which builds queries for all ports, APs, radios, etc.) 

The proposed solution is to augment the TxnConrroller to use a database technique called MROW 
(multiple readers, one writer). MROW is desirable as it allows for concurrency without complete 
serialization. The following sections provide an overview of how MROW can be fitted into the current 
TxnConrroller with minimal impact to other clients. 

8.1 USER VISIBLE FEATURES AND CHANGES 

<This section needs to describe all of the user visible features that have to be modified to use the new 
infrastructure and ultimately what QA need to re-test> 

8.2 CURRENT TRANSACTION FLOW 



commit 



Start/Finish 



Base Config 




Root 

Change Set 


« — > — ► 


« 





Transaction 



Start/Finish 
< ► 



Transaction 



Change Set 



Change Set 



The figure above depicts the flow of a transaction with the current TxnConrroller. As soon as any 
client starts a transaction, that transactions change set is visible to any other client wants to use the txn 
controller. This implies that no other client can use the transaction controller in isolation from the state of 
the original client. This is not good as it violates the "I" (isolation) in ACID, and also forces serialization of 
read & write operation across clients. 

However, in the case of nested wizards isolation of state is not needed as each wizard wants to build on 
the model state of the prior wizard. This is also true, when one part of the application wants to pass-in its 
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state to some other part (like a common method.) Hence, any proposed change must allow for sharing of 
state, as well as isolation of state, depending on the needs of the application. 

8.3 PROPOSED FLOW 





w Transaction 


<- 


^ Transaction 
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L Change Set 




Change Set 


commit 










Base Coniig 
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Change Set 
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Change Set 






Change Set 
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Conceptually, the proposed change is to allow a multiple transaction chains to be branched on top of 
the model (base configuration & change set.) The state of each transaction chain is isolated from the other 
transaction chains. 

A client can pass its current state to some other part of the application, allowing nesting of operations 
that build on prior state. 

When a chain completes and its changes are to be merged to the Change Set (CS), or a commit 
operation is to be performed, a lock must be taken. Otherwise there is no locking or synchronization 
overhead. 

This will allow background managers to start their own transaction chains and safely work in isolation 
from the rest of the application. Once they perform the necessary tasks the background managers can 
simply cancel their transaction chain, as they do not need to write to the model. 
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8.4 PROPOSED DESIGN DETAILS 



The concept of isolated transaction chains solves the problem. But these need to be implemented 
without disrupting the current clients of the TxnController. How this can be achieved is discussed below: 



8.4. 1 TXN CONTROLLER SPLIT 

Currently the TxnController interface is implemented by a single class, the TxnControIlerlmpL The 
TxuControllerlmpl is instantiated and stored in the NmsFrame, and all other application modules access the 
TxnControllerlmpl via the frame, and use the interface TxnController. As mentioned before, background 
managers contain a separate instance of the TxnControllerlmpl. 

The proposed design is to partition the TxnControllerlmpl into two separate roles: 

• a DataStore that contains the current model base and pending changes 

• TxnController that can be used to manage multiple transaction chains 

With the proposed design, the impact to the existing application is minimal. Using a factory, the 
NmsFrame will obtain an instance of the RW_TxnController. All application modules that use the 
"getTxnControlIer" method will access this instance, and operate on it as before. 

Background managers will use a factory to get an instance of a RO_TxnController. They can use this 
to read application state and safely parse network updates while wizards are active. 



TxnController 
Factory 



TxnController 
«interface» 



AbstractTxnControl ler 
«abstract> 



> ROTxnController 



> RWTxnConrroller 



Object Cache 



3n 



Base Config 



Change Set 



1 



0..* 



Transaction 
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8.4.1.1 OBJECT CACHE 

The ObjectCache is a subset of the current TxnConrrollerlmpl. It takes over the role of keeping the 
common model state i.e. the base config and the change set, and is responsible for synchronizing changes 
to the model state. 

The ObjectCache is ignorant of the currently open transactions. The ObjectCache allows multiple 
transaction chains to be active on top of the shared view of the data. 

The ObjectCache is not visible outside of the txn controller package. It is only accessible via the 
TxnController. 



8AA.2 READ-WRITE TXN CONTROLLER 

The RWTxnController is a TxnController that allows changed state to be written into the 
RootTxnController. The RWTxnController fetches objects from the RootTxnController as needed. As 
changes are being made, the object is then cached within the RWTxnController itself 

When the last transaction is finished, the RWTxnController invokes a merge into the Data Store. While 
this is in progress, no other operations can be performed on the DataStore i.e. it is locked. 

The RWTxnController also supports the "commit" call which allows model data to be moved from the 
Change Set to the Base Config. 



8. 4.1.3 READ-ONLY TXN CONTROLLER 

The ROTxnController allows object level modifications, but does not allow any of these changes to be 
merged back to the Data Store. When a final finish is done, or a cornmit is invoked, any changes made in 
the read-only txn controller are discarded. 

This implies that the ROTxnController is useful for making temporary changes. For example, when 
parsing device stats/status a ROTxnController can be used and once the stats objects are created client 
obtains and caches them as needed. 



8.4.1.4 TXN CONTROLLER FA CTORY 

When the application is launched a Object Cache must be created, and a Txn Controller Factory must 
be seeded with the Data Store. The NmsFrame will cache an RWTxnController which will be used for all 
model changes. 

The factory will be used to create multiple ROTxnController objects. Initially we can restrict the 
factory to produce a single RWTxnController as this helps avoid adding complex logic to handle optimistic 
or pessimistic object-based locking (see "What if we needed multiple writers...") 



8.4.2 COORDINATING WRITES 

MROW does not prohibit multiple writers. It requires writes to be coordinated across clients so that 
only one client is allowed to write at a given instance in time. This is typically done using locking. There 
are two common variants: 
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• Optimistic locking: where there is an initial presumption that conflicts will *not* occur, and so no 
locking takes place until changes are completed and ready to be merged to the data store. 

• Pessimistic locking: where locks are granted up front at various levels of granularity and while a 
lock is held, all other clients pend on it. This scheme is typically based on a timed lock. 

There are pros-and-cons to either approach. Optimistic locking is easier on the clients, but requires 
more complex merge logic. Depending on the implementation details and the order m which clients finish 
their transactions, it can introduce some timing inconsistencies in the data (unless it rejects a merge based 
on a conflict.) Pessimistic locking requires more synchronization and needs clients to deal with locks and 
more importantly being denied locks. But, it eliminates any potential for inconsistencies. 

In the current application all modules that need to update the model will coordinate their operations via 
the NmsFrame (using get/set busy methods.) Hence there is really no need for multiple writers. To leverage 
this, instead of requiring any synchronization or merge logic, we can enforce the single writer by having the 
factory/frame only contain a single instance of the RWTxnControlIer. If & when needed, this scheme can 
be seamlessly extended to support multiple writers and the proper write coordination logic. 

8.5 FUTURE APPLICATIONS.... 



8.5. 1 WHAT IF WE WENT CLIENT/SERVER 

The proposed design can adapt well to a distributed model. Each client can have one or more of its 
own read-only or read-write TxnController instances and the Data Store can reside in the server. 

By performing all object operations locally, and without any synchronization overhead, clients can be 
extremely efficient. When changes are ready to be merged, an entire Change Set can be transferred back to 
the server. 

8.6 DELIVERABLES & ESI MATES 



8.6.1 GENERAL 

With the new design, all background tasks can be safely performed using a ROTxnController. A client 
that wants to process a network response in the background can use a ROTxnController to parse the XML 
and create RTime objects. Once these are parsed they can be cached in the StateMonitor or propagated 
back to other modules, like in the case of stats collection. 

The DeviceStatManager, OperStarusPropogator and Client management module need to be updated to 
do this. 



8.6.2 CLIENT MANAGEMENT 

The client management module uses a mix of dynamic and configuration data. For background tasks it 
needs to be updated to use a ROTxnConrrolIer (like the DeviceStatManager, etc.) 

Here js an initial analysis of the changes necessary for this module: 

• We need to have a ClientMgr singleton object which maintains a ROTxnController. ClientMgr will be 
instantiated whenever a user opens a new plan and disposed whenever a plan is closed. 
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• ClientMgr will open a long transaction using a ROTxnContr oiler instance, and will listen to APRadio 
delete events since it actually establishes the reference relations from current user location to the AP 
radio. If a radio is deleted, the ClientMgr's ROTxnController will need to be updated. 



• ClientMgtPanel and FindUserWizard will both use this ROTxriControIler to do create and delete or 
modify of the user sessions and user locations whenever we perform find Users, or polling users from 
background 



• ClientMgtPanel will no longer need to cache the data, and it will use the ROTxnController to update 
the user session and user location data. And when it is doing background polling, it will not need to set 
the frame to be busy since it is operating on a different transaction controller. 



• Since ShowUserLocation() method in ClientMgtPanel sends FloorLayoutEventData to FloorMdlView, 
this event data will need to have slight interface change to pass in session label, rssi, and AP radio key 
(which MX, MP, and Radio Slot) instead of passing session id and radio id. This is because the session 
now is no longer created in the main RWTxnController; we need to de-couple the usage of the id. 

8.6.3 ESTIMATES 

(Estimates include unit testing) 

1 . Infrastructure changes (with single RWTxnController support) - 5 days 

2. Devif - DeviceStatManager changes - 2 days 

3. Oper Status Propagator changes - 1 day 

4. Client management/Find Client - (3 days) 
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9 VERSION1NG 

Moving forward Ringmaster will need to support multiple versions of software and maintain a level of 
compatibility between them. 

9.1 XML CONVERSION 

9. 1 . 1 DEVICE DTD COMPATIBILITY 

9.I.J.] PA TCH RELEASES 

For patch releases a DTD needs to be backward compatible. That implies that a 1 .O.x+1 DTD must be 
able to validate a 1 .0.x XML. 

In order to achieve this some rules must be followed: 

• Only optional attributes can be added 

• Only optional elements can be added, and they must be at the end i.e. no change in document 
order for existing elements. 

• No other changes are allowed 

9.1.1.2 MAJOR/MINOR RELEASES 

Need to clarify what is supported. Possible changes??? 

• attribute is added 

• attribute is removed 

• attribute is modified 

o Type changes 
o Range changes: 

■ Enum list extended 

■ Enum list shortened 

■ Numerical ranges? 

■ String lengths? 

• element is moved 

• element is removed 
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• element is added 



9.1 .2 VERSION CONVERTORS 

The proposal is to develop a set of version converters which will be implemented as JAXP 
Transformer instances (see JAXP documentation) to convert between various versions of the XML. Each 
transformer will transform the XML between two immediate versions. For future conversions across 
multiple versions transformers can be chained together. 

A transformer will typically be implemented by an XSLT stylesheet. Each stylesheet can consist of 
multiple templates (templates are like procedures in XSLT) for various conversions. 

A transformer can also have an implementation that converts directly between two DOMs i.e. it is not 
required to be a XSLT stylesheet. 

For example, the policy data may change between 1.0.0 & 1.0.1. To handle this, a "1.0.0 to 1.0.1" 
transformer will be created and registered in a Transformer Factory. When a client module encounters a 
1 .0.0 XML and wants to convert it to 1.0.1, it will lookup this transformer and will run it to produce a 1 0 1 
XML. 



Version Convertor Factory 



+getConvertor() 



JAXP::Transformer 



^ transforms 

s: 



Version Convertor 



+getFromVersionO 
+getToVersion() 



3£ 



Version Convertor ImpI 



Aggregate Version Convertor 



« utility » 
XSLT Stylesheet 



Depending on how complex the conversion is we can also support an aggregation of converters for a 
single conversion. So for example, assume that a conversion has the above mentioned policy changes and 
also has a new AAA/userglob hierarchy. We can develop independent Version Converters for each 
conversion, and then somehow aggregate them together for the full conversion. If we find the conversion 
getting too complex, this approach may help in breaking it into simpler pieces. 
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10 RULES SUPPORT 

We have added additional support for Rules Check in RingMaster release 1.1. For details, please refer to 
the Rules-Spec document. Here is only a summary of a list of rules added for release 1.1 : 

1 . Accounting for MAC Network Access is not supported. (Error) 

2. AAA User/UserGroup, Mac User/Mac UserGroup Attributes validation: 

a. Moblity-Domain Profile should exist in the device (Warning) 

b. Service-Type needs to be numberic value (1-11) (Error) 

c. Encryption-Type needs to be numeric value (0-64) (Error) 

d. Session-Timeout needs to be non-negative number (>0) (Error) 

e. Idle-timeout needs to be non-negative number (0-65535) (Error) 

f. Filter-id needs to postfix with either *.in or *.out (Error) 

3. AAA Radius Server "key" should be set if Radius Default did not set the default for "key" 
(Warning) 

4. AAA Radius Server can not have ip addresss as 0.0.0.0 (Error) 

5. Mobility-Profile should contain at least 1 port group reference if the mode is defined as Selected. 
(Error) 

6. ManagementServices Sys Log should have maximum of 4 log servers. (Error) 

7. ACL name should start with alphabetical characaters. 

8. ACL name should not contain the following terms: all, default-action, map, help, editbuffer 
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11 M1SC CONFIG SUPPORT 



We have also added the configuration support in R 1.1 for the following (was unsupported in R1.0): 

• VR-ARP configuration: One can now configure VR-ARP agingTime, and ARP Entries (hw-addr, 
and ip-addr), deploy, and review network changes etc. 

• Trace-Table configuration. One can now configure Trace-Table, setting up different trace area, 
levels, deploy, and review network changes etc. 
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12 EVENT VIEWER ENHANCEMENTS 

Several new features will be added to to the event viewer in R 1 . 1 

• The user must be provided with the ability to enable or disable the auto-refresh functionality. 

• The user must be able to specify AND and OR conditions when specifying text search criteria i: 
the event filters. 

• A function to find a string within a message must be provided in the detailed view dialog. 
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13 APPENDIX 

13.1 NNM APPLICATION REGISTRATION FILE DEFINITION 

Application registration files are used to integrate network and systems management applications with 
the NNM user interface. Many aspects of an application's integration are defined using an application 
registration file (ARF). Application registration files provide NNM with important information such as: 

• How to integrate the application into the NNM menu and Toolbar structure 

• How to invoke the application based on the user's run-time selection of menu items 

Ex: 

Application "RingMaster" 
{ 

/* 

** APPLICATION DESCRIPTION 
*/ 

DisplayString "Trapeze Networks Planning Tool" 
Version "RingMaster 1.0" 
Description { 

"Description " 

} 

Copyright { 

"Copyright information " 

} 

/* 

** COMMAND BLOCK 

*/ 

/* 

** Valid Process_f lags are Initial, Shared and Restart 
*/ 
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Command - [process_f lags] "command_name" $envi ronment_variable ; 

/* 

** MENU BLOCK 
*/ 

MenuBar <100> "Tools" _T 

{ 

<10> "Trapeze Networks" _z Context (AllContexts) f .menu 
"trapeze" ; 

} 

Menu "Trapeze Networks" 

{ 

<100> "Ring Master" _R Context (AllContexts ) f. action "ringmaster" ; 

<90> "Event Viewer" _E Context (AllContexts) f. action "eventviewer" ; 

<80> "RF Detection" JD Context (AllContexts) f. action "rf detect ion" ; 

<70> "Client Management" _C Context (AllContexts) f .action 
"clientmanagement" ; 

} 

/* 

** TOOLBAR BLOCK 
*/ 

ToolBarButton <50> ©"toolbar/ringmaster .bmp, RingMaster" 
Context "AllContexts" f. action "ringmaster" 



/* 

** SYMBOL POPUP MENU BLOCK 
*/ 
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Popupltem <100> "RingMaster" 
Context AllContexts 

TargetSymbolType "Net Device" : "Trapeze MX-20 switch" 
f. action "ringmaster"; 
Popupltem <90> "Event Viewer" 
Context AllContexts 

TargetSymbolType "Net Device" : "Target MX-20 switch" 
f . action "eventviewer" ; 
Popupltem <80> "RF Detection" 
Context AllContexts 

TargetSymbolType "Net Device" : "Target MX-20 switch" 
f . action "rf detection" ; 
Popupltem <70> "Client Management" 
Context AllContexts 

TargetSymbolType "Net Device" : "Target MX-20 switch" 
f . action "cl ientmanagement" 

/* 

** ACTION BLOCK 
*/ 

Action "ringmaster" 

{ 

Command -shared "ringmaster" -p $NNM_RM_DEFAULT_PLAN ; 

} 

Action "event viewer" 

{ 

•Command -shared "ringmaster" -p $NNM_RM_DEFAULT_PLAN -f "event"; 
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} 

Action tt rf detection" 

{ 

Command -shared "ringmaster" -p $NNM_RM_DEFAULT_PLAN -f 
"rfdetection" 

} 

Action w cl ientmanagement " 

{ 

Command -shared "ringmaster" -p $NNM_RM_DEFAULT_PL*AN -f 
*cl ientmanagement" 

} 

NNM SYMBOL REGISTRATION FILE DEFINITION 

SymbolType "class Name" : "subclass Name" 
{ 

Filebase "symbolclassiconbasenaroe"; 
CursorSize n; 

DisplayString "localizable String"; 

} 

Ex: 

SymbolType "Connector" : "Trapeze MX-20 Switch" 
{ 

Filebase "trpzmx20"; 
CursorSize 38; 

DisplayString "Trapeze Networks MX-20 switch"; 

) 

In the above symbol subclass definition subclass name needs to be unique. 
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Filebase defines the base name for a symbol subclass. It is provided in a File with the format 
filebase.size.extensibn Symbol class icon can be an X bitmap or X pixmap. Pixmap is a supported format 
for UNIX and Windows. 

Bitmap definition is composed of two parts filebase.size.p (the bitmap) and filebase.size.m (the bitmap 
mask). Pair of bitmap/bitmap mask file pair should be provided for each bitmap size. Recommended 
symbol subclass icon sizes (in pixels): 20X20, 26X26, 32X32, 38X38, 44X44 and 50X50. All icons for a 
subclass must be of the same format. Pixmap definition consists of simply filebase.size.pm because the 
mask is defined in the pixmap (Need to investigate whether GIF or JPEG can be used instead of pixmap or 
bitmap files) 

CursorSize entry defines the size of the bitmap to be used as the cursor. CursorSize is also used during 
drag and drop operation. Recommended cursor size is 38X38. 
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1 INTRODUCTION 



1.1 GOALS AND SCOPE 

The goal of this document is provide a functional specification of the changes to RingMaster for Version 
2.0. 

The following main features are targeted for 2.0: 

• MX-6/MX-400 Support 

• Intermediate L2/L3 MP Support 

• Policy Management Changes 
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2 NEW DEVICE SUPPORT (MX-6, MX-400) 



2.1 OVERVIEW 

The MX-6 is a smaller version of the MX-20, with 8 ports (6 fast Ethernet and 2 gig-ethernet.) The 
MX-400 is a 4 gig-port chassis. From a software perspective the MX-6 & MX-400 are the same as the MX- 
20. Please refer to the appropriate PDDs for more product details. These are available at: 

http://intranet.trpz.com^ 

The following sections elaborate on the areas of Ringmaster that need to be changed to handle the new 
MX types. 

2.2 CONFIGURATION MANAGEMENT 



2.2.1 DTD CHANGES 

The DTD needs to be modified to have a chassis type attribute as part of the boot status. Ringmaster 
will use this attribute wherever it needs to check the network type (e.g. Topology reports, deploy, upload, 
etc.) This is similar to how the version is read & processed today. 

2.2.2 MODEL CHANGES 

There are no new classes for the new device types. The existing Chassis class and the existing Network 
Plan -> Device relation will be used to model MX-6 & MX-400 instances. Note that this implies that the 
chassis names are unique across all types of chassis. 

There is currently a "MX Model" RO attribute on the device, that displays the system description 
value. This will now be used as a RC attribute that allows the user to select an MX model. The system 
description will be shown in the SNMP properties (as it is also done today.) The MX model will be an 
NMS only attribute i.e. not part of a deployable config. 

New Device Descriptors will need to be created for each type of MX. 



2.2.3 VERSIONING 



The MX-6 & MX-400 will only allow v2.0 and up (see table). 





1.0 


1.1 


2.0 


MX-20 


Y 


Y 


Y 


MX-6 


N 


N 


Y 


MX-400 


N 


N 


Y 
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Since the same model classes are used for all types of chassis', the allowed configurable software 
versions for the MX-6 & MX-20 will be different based on the instance type (controlled via 
"getValidChoices") 



2.2.4 MX CREATION - LOCAL 

Users will now need to specify which type of chassis they wish to create. Based on the selected option, 
the right Device Descriptor will be used to create the default objects for the chassis. 




Internally, when the chassis type is selected a default Chassis object is created and set as the context. 

NOTE: If the user comes back to this page and selects a differentMX type, the context will be deleted 
and re-created. 



2.2.5 MX CREATION - UPLOAD 

During an upload, Ringmaster will determine what type & version of chassis to create based on the 
system boot status returned from the MX. Once a chassis is created, the XML config is mapped on to it. 



2.2.6 MX CREATION - OTHER (OPEN PLAN, IMPORT, PASTE, ETC.) 

When opening a plan, Ringmaster will use an NMS-only "chassis-type" attribute to determine the type 
of chassis to create. The same approach will be used for a paste. 

For an import or a paste-replace where the device already exists, its type will not be changed but the 
data will be applied. More details on this in subsequent sections. 



Trapeze Networks Confidential 



Page 7 of 45 



Ringmaster 2.0 Functional Specification 



Revision: 0.12 



2.2.7 • CHASSIS MODIFICATION 

The user will not be allowed to change the type of a chassis after it is created (i.e. the create wizard is 
finished.) Within the create wizard the user can go back to the chassis selection page and start over. 

2.2.8 NETWORK SYNCHRONIZATION 

RingMaster will only allow network changes to be applied to the plan if the type of the MX in both the 
network and RingMaster configuration are the same. If network changes are detected, but the types are 
different, the Network Status field in the Local & Network Changes view will indicate the model 
mismatch and the apply button will be disabled for that MX. 



2.2.9 DEPLOY & DISTRIBUTE IMAGE/CONFIG 

When sending configuration and images to the network, Ringmaster will check and verify the device 
type. This will be done along with the existing license & version checks, before any configuration is sent. If 
there is a mismatch, an error will be shown and the operation will fail 



The image distribution and configuration page will need to be modified in way that the image selection 
button is disabled whenever the user selects multiple MX's of different types. A new MX type column will 
be added to help the user properly select multiple MX's. 




2.2.9. 1 BUTTON/UI CHANGES 

Both the Deploy & the Distribute Images & Configuration have some UI issues. 

The Deploy page has a button on the top right. This should be moved to the side or the bottom. The 
Distribute Images & Config has the "Start Download" button on the side. This should be moved to the 
bottom panel. 
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2.2. 10 XML MAPPING IMPLEMENTATION NOTES 

This behaviour is common to all functions like copy &paste/paste-replace, import, upload, etc. 

Although a device type cannot be changed via parsing XML, any configuration can be parsed onto any 
type of device. Hence, the XML mappers will have to be flexible enough to handle parsing of data that may 
not be completely valid in a best-effort manner. 

The main issue is with port references, which can be used in VLANs, ACL Maps, etc. So if a MX-20 
VLAN containing port references to port 10 is copied to an MX-6 the expectation is that the VLAN will be 
properly copied but the VLAN-PORT that is invalid in the target will be ignored. The way this can be 
handled is if the key reference is not resolved, the mappers do not create the containing object (like VLAN- 
PORT.) 



2.2.11 COPY/PASTE/PASTE REPLACE 

RingMaster provides useful features to allow the user to copy/paste/paste replace configurations within 
the supported configuration elements of the network. It is required for the user to be able to 
copy/paste/paste-replace between heterogeneous MX types. That is, the user should be able to copy and 
paste a VLAN from an MX-20 to an MX-6. Similarly, a user should be able to paste-replace from an MX- 
20 to an MX-6 without any significant problems. 

The device type attribute will not be applied as the type of an existing device cannot be changed via a 
copy & paste-replace. For a paste that creates a new device, the type will be the same as the source device. 

Just as with copying and pasting across versions, copying and pasting across types will be best effort. 
This means that only data that is valid in the target will be applied. So, in the VLAN example above if the 
source VLAN contains port references that are j\ot valid in the target device, these will not be created. 



For ports, the configuration will be aligned based on port type and port number. This means that based 
on the incoming chassis type, the target chassis type, and the incoming port number there will be a best 
effort attempt to calculate the target port and apply the configuration to it. 




2.2. 1 2 CONFIGURATION FILE IMPORT 

The CLI-based configuration must include a type descriminator to allow RingMaster to build the 
correct chassis type. This has traditionally been done by a standard comment field at the top of the CLI- 
based file. We need to define such a standard and incorporate support for this into RingMaster. 

When a file is selected, and if it is a CLI file Ringmaster will parse the header and determine the type. 
If the header is missing, or not properly formatted the user will need to select the device type. For XML 
files, Ringmaster will use the number & type of ports to determine the chassis type. In either case, the user 
can always change the device type. 



Trapeze Networks Confidential 



Page 9 of 45 



Ringmaster 2.0 Functional Specification 



Revision: 0.12 




2.2.12.1 OVERWRITE EXISTING MX SWITCHES 

Currently, the overwrite option really does a merge. This will be modified to make the device config 
look exactly as in the imported file. This implies that a partial configuration can no longer be applied to an 
existing device. 

If the overwrite option is selected, and the MX types do not match the import will fail. 



2.2.12.2 CLI HEADER FORMAT 



Here is a proposal for the CLI header (only the "Model" line is new): 

15:32 :08 



# Configuration nvgen'd at 

# Image 1.1.0.67 

# Model MX-400 

# Last change occurred at 



18 :12 : 12 



2.2.13 CONFIGURATION FILE EXPORT 



RingMaster provides the user with the ability to export CLI-based configuration files. It must be 
extended to enable creation of configuration files for the MX-6 & MX-400, including the standard type 
header for the file that specifies the MX type. 
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2.2 A3 A VER1FICA TION ON EXP OR T 

Currently we do not run rules on export of configuration. When the user selects the export option, just 
as in the deploy wizard, we should run the verification rules and display any errors. The display could be 
done as a separate "View Errors/Warnings" button on the export dialog. The same preferences that are used 
today will be used to control whether a configuration with errors can be exported etc. 

It would be nice to show the error on a per device basis, and only enable/disable export of that device. 
This would require some modifications to the verification engine as currently there is no way to request 
verification on certain sub-trees. 



2.2.14 VERIFICATION/RULES ENGINE 

Other than the physical port count, Ringmaster will not impose configuration limits on VLANs, ACLs, 

etc. 

Ringmaster will have logic to retrict the Distributed AP count for different types of MXs. This is 
covered in the section for the L2/L3 MP support. 

2.3 IMAGE MANAGEMENT 
2.3.1 IMAGE FILE 




The embedded XML header in the image file will need to be modified to include a device type. The 
image file parser will read this and hence be able to determine what type of chassis an image is for. 
Ringmaster will also need to handle the case where the model is missing i.e. for 1.0 and 1.1 images. These 
will be assumed to be MX-20 images. (The case where a 2.0+ image is missing this information is an 
error.) 

The proposed format is: 

<image-identif ier product= "MX" model= "MX-20 " version= " 1 . 1 . 0 . 76 

label ="QA_1 .1 . 0 filename="MX010100.020"> </image- ident if ier> 



2.3.2 IMAGE REPOSITORY 

The image repository will need to be extended to manage images for the new MX types. When adding 
an image, RingMaster will need to detect the type manage it accordingly. When the user configures an 
image for a chassis, only images that match the chassis type will be shown. 
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2.3.3 IMAGE CONFIGURATION 

When the user selects an image for an MX, only the images that map to the MX model should be 
shown. This implies that the image repository will need to support functions to retrieve images by MX 
model. 

2.4 PERFORMANCE MANAGEMENT 

The following sections outline the changes that will be required for MX-6 support in the area of 
performance management. 



2.4. 1 PERFORMANCE DATA AGGREGATION 

There is no user-level change for the PM aggregation. However, there are places where the 
implementation will need to be updated to not assume 20+2 ports. 

2.5 FAULT MANAGEMENT 

The following sections outline the changes that will be required for MX-6 support in the area of fault 
management. 



2.5. 1 OPERATIONAL STATUS MONITORING 

Similar to the performance aggregation, there are no user visible changes but there will be code 
updates to not assume a 20+2 port configuration. 

2.6 POLICY MANAGEMENT 

NOTE: There are significant changes proposed for policy management in a differents section of this 
document. Here for the purpose of decoupling the two features we describe how the current policy 
management scheme can work for the MX-6 with no changes. 
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The current policy management scheme assumes that the policy is an MX-20 device. For other 
functions like copy-paste, import, etc. the XML mappers will need to do be flexible enough to handle 
applying MX-20 data to an MX-6. Hence, when a policy is applied to an MX-6 only data that is valid for 
the MX-6 will show up as changed. This is also how the current policy scheme works for different 
versions. 

Note that even with all of the proposed policy changes, we will need to handle cases where a user 
defines a VLAN policy without policy-criteria (in which case it would need to be based on a superset of all 
possible configurations.) 



2.7 RF PLANNING 

As part of the design constraints, RingMaster RF Planning will require the user to now select the 
appropriate chassis type they wish to deploy in their network. 

The algorityhms which try to determine and allocate ports now must take account of the chassis type 
and the various port configurations. 

2.8 RF DETECTION 

RF Sweeps may be considerably different when the MX-6 ships due to the lower-cost hardware and 
limitations. Therefore it is expected that there may be additional software required in RF detection control 
and configuration for this new hardware. At a minimum, the RF detection wizards and results pages must 
be able to handle different chassis types and possibly results. 

2.9 REPORTS 

The following sections outline the changes that will be required for MX-6 support in the area of 
reports. 

2.9. 1 NETWORK TOPOLOGY VERIFICATION 

Network topology verification is an important feature in RingMaster that becomes more important as 
different chassis types can exist in the network. Verifying that the MX type matches the network plan. ..etc 
is an important extension of this logic. 

2.9.2 INVENTORY REPORT 

The inventory report will need to identify the MX type for all chassis listed. 

2.9.3 WORK ORDER 

RingMaster work-order generation will require additional features to show the user chassis types as 
part of the report. 
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Task 


Estimate (Days) 


DP Simulator changes (boot status, etc.) 


1 


Model Changes, Versioning and MX Creation 


5 


MX Upload 


2 


Deploy (+button/UI changes) 


2 


Distribute Image/Config (+button/UI changes) 


2 


Devif updates to retrieve & cache MX type. 


1 


Change Management (Accept changes) 


1 


XML Mapping to map ports across devices 


2 


Copy & Paste/Paste-Replace 


5 


Import & Export 


4 


Verification on Export 


3 


Image Management 


3 


PM & Oper Status 


2 


RF Planning - port allocation 


1 


RF Detection 


?? 


Network Topology Report 


2 


Inventory Report & Work Order 


2 
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3 



DISTRIBUTED MP (DM P) SUPPORT 



3.1 OVERVIEW 

The significant change to the management model for support of MX/MP separated by an intervening 
L2 or L3 network is related to the pre-configuration steps the customer now has to perform. 

This section will define the changes to and impact on RingMaster with the introduction of Distributed 
MP (DMP). 



3.1.1 FEATURE SUMMARY 

The complete details of feature requirements are in the 
htrp://intranet.tipz.cor^ 

The goal is to integrate Distributed MPs into RingMaster seamlessly ensuring all features of 
RingMaster function normally. 

To summarize the features in RingMaster perspective: 

• Ability to configure a DMP 

• Ability to configure n- Redundancy for a MP 

• Ability to plan with incomplete DMP configuration 

• Ability to update the MP configuration from its announce status 

• Ability to monitor MP that has at least one "indirect-connection" 



3. 1 .2 DISTRIBUTED MOBILITY POINT (DMP) 

A DMP is an access point connected to a MX port with an L2/L3 network in-between them. It is the 
ability to allow users to place Access Points in remote locations where the Ethernet cable length limit of 
100 meters is an issue. 

Simply put, an Access Point is a DMP, if it is not directly attached to a physical port; 

Typical usage of DMP is to place in remote offices, where 1 or two access points are required and it is 
dangerous or management nightmare to place a MX in a wiring closet. 

DMP is just like another MP. RingMaster will not distinguish between them, except when it comes to 
deploy such configurations as certain information will be required for MP to receive its configuration from 
the MX. The user will continue to define an Access Point, the way it is currently defined. The only 
difference being that the user needs to make it clear when configuring MP on a MX. if it is connected to a 
physical numbered port or if it is a DMP. 

In this document, a "direct-connect" indicates that the MP is directly connected to a MX port. And 
similarly, a "indirect-connecf ? indicates that the MP is indirectly connected to the MX via a L2/L3 network 
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MX1 



MX1 



MX2 



MP 



MX1 







MP 





MX1 



MX2 



MP 



L27L3 



MX1 



7 



L2/L3 

~1~ 



MX2 



1„n 



L2/L3 



MP 



CF 



L2/L3 



MP 
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3.2 USE CASES 

The two ways of configuring MPs, i.e.; RP Planning tool or manual MP configuration will continue to 
be supported with the introduction of DMP. As always, creating new MP configurations is recommended 
by using the RF Planning tool. 

In order for RF Planning tool to be able to generate MP Configurations, it will need some information 
in addition to what is requested in the current release. 

3.2.1 USAGE OF RF PLANNING TOOL 

The work flow of using RF Planning tool will be as follows: 

1 . User draws coverage area and provides its details. 

2. User manages Design Constraints on the Coverage Area before attempting "compute and place" 

3. Upon Compute and Place, the RF Planning tool will create MP with "direct-connection" or 
"indirect-connection" to MXs. The planning tool will also add the desired redundancy to the MP. 

3.2.2 DEPLOYING DMP CONFIGURATIONS 

1. The user creates MP with one ore more "indirect-connections" either manually or using RF 
Planning tool. 

2. The user specifies the "mandatory" serial number for each MP that has at least one "indirect- 
connection" 

3. The user deploys the MP configuration 

3.2.3 MANAGING DESIGN CONSTRAINTS 

As in the current release, the user has no flexibility of managing Design Constraints per Coverage Area 
with 2.0; RingMaster will allow the user to manage the constraints at an area level. More details about this 
can be found in section Enhancements to RF Planning. The ways to manage design constraints will be as 
follows: 

1 . User clicks on Manage Constraints action 

2. User applies certain constraints to selective Coverage Areas. 

3. User edits a Coverage Area 

4. User modifies the Design Constraints of the area independently. 
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3.2.4 CREATE A NEW DISTRIBUTED MP 

To distinguish from creation of a "direct-connect" MP in Ports Wizard, the user will be able to create a 
DMP in a particular device. However, the user will not be able to add redundancy to the MP while creating 
the DMP. The user will have to edit the DMP to add /remove / move redundancy. 

3.2.5 MANAGING MP CONNECTION INFORMATION 

1 . The user edits the MP 

2. The user adds/modi fies/removes redundancy to MP connection by adding/modifying/removing 
"connection information" 

3.2.6 UPLOAD DMP CONFIGURATION 

1 . The user creates a DMP configuration on CLI 

2. The user uploads the configuration from MX into RingMaster 

3. RingMaster creates a Distributed MP for any DMP configurations found. 

3.2.7 CLI IMPORT/EXPORT 

RingMaster will be able to handle export and import of Distributed MP just like any other piece of 
configuration. 

3.2.8 COPY/PASTE/PASTE-REPLACE 

The user will be able to copy/paste a Distributed MP on another Distributed MP, but not on an AP 
object shown under "Ports/ APs" folder. 

3.2.9 REBOOT DIALOG 

The user will be able to select a Distributed MP for a reboot. 

3.2.10 INVENTORY REPORT 

Appropriate changes will be done to the inventory Report to handle Distributed MPs 
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3.3 INFORMATION MODEL 

3.3.1 DISTRIBUTED MP 

An MP with "indirect-connection" will have the following additional attribute to define a Serial 
Number that will define it unique in the entire network. It will have all the common attributes and 
restrictions that can be had on a "direct-connect" MP. 

3.3.1.1 DMPID 



DMP ID is the key of DMP. DMP is identified by an ID. The range of ID allowed for a DMP depends 
on MX type. The user will identify DMP configurations by this ID. Creation, modification or deletion of 
DMP configurations will be based on the DMP Port ID. 



MX Type 


DMP ID Range 


MX-20 


1..40 


MX-6 


1.8 


MX-400 


1.100 



3.3.1.2 SERIAL NUMBER 



Serial Number, a text field, has the following properties: 

1 . It is not mandatory to be entered to create the MP 

2. It is required to be entered before deployment of configuration, if it is a "indirect-connect" in 
one of its port configurations 

3.3.2 MOBILITY POINT 
3.3.2.1 IP ADDRESS 

This is an ip address on the Mobility Point and is not configurable. However, this information will be 
visible in property panel of the mobility point. 



Trapeze Networks Confidential 



Page 19 of 45 



Ringmaster 2.0 Functional Specification 



Revision: 0.12 



33.3 DESIGN CONSTRAINTS 



The Design Constraints that can be applied on the entire floor or an individual Coverage Area. 
Changes to Floor Design Constraints, will be applied to any new Coverage Area that is created, unless the 
user applies them to a selective set of Coverage Areas. 



Design Constraint 


Description 


Default 


Comments 


Use MX Type 


MX-20, MX-6, MX-400 are the choices. 
This defines the type of MX that will be 
created by the planning tool 


MX-20 




MP Connection Type 


If any new MP is to be created, it will be 
created using user selection "direct- 
connection" or" indirect-connection" to 
first available port/DMPID in an MX 


Choices are 
Direct and 
Distributed. 
Direct will be 
selected by 
default 


If the MX type is 
MX-400, it will 
always be a 
distributed MP 
that will be 
created. 


Compute Redundancy 




Unchecked (no 
Redundancy) 




Use Same MX 


If checked, the redundancy can be 
through the same MX from which the 
primary connection to MX was 
computed 


No 




Redundancy MP 
Connection Type 


When a redundancy is desired, this lets 
the planning tool know if the redundant 
connection to MP should be "direct- 
connect" or "indirect-connect 


Choices are 
Direct and 
Distributed. 
Direct will be 
selected by 
default 


If the MX type is 
MX-400, it will 
always be a 
distributed MP 
that will be 
created. 


Number of Redundant 
level 


This is applicable only if Distributed 
MPs are desired for redundancy. 


1 


Test for 4 
Max : 20 


Allow Deletion of Locked 
MPs 


Deletes the unwanted locked MPs upon 
compute and place 


Yes 
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3.3.4 COVERAGE AREA 

The Coverage Area wizard will have an additional page to edit its design constraints. When the area is 
created, it gets its constraints settings from what is set on the floor. 




3.4 ENHANCEMENTS TO RF PLANNING 

This section will cover the impact on RF Planning. Some constraints will be defined for the user to 
make it clear for the planning tool to be able to create MP. 



3.4. 1 DESIGN CONSTRAINTS MANAGEMENT 

A new action will be added to ''Compute and Place" page to apply design constraints at a global level 
to coverage areas within a floor. Current design constraints page in Compute and Place MP wizard will be 
removed. 
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Clicking on Manage Constraints action will launch a wizard shown below where user can apply design 
constraints for all the coverage areas in a floor. 

Select the constraints and the area(s) and clicking on next button will apply the constraints to selected 
areas and will show the progress. From the progress page user can click finish to commit the transaction or 
click cancel to cancel the changes. From the progress page user can click on previous button to come back 
and apply new constraints to different set of areas. 
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3.4.2 MP COMPUTATION 

During computation of MP for the area, design constraints set for that coverage area is used to create 
distributed MP or direct-connected MP. 

In case of shared areas changing design constraints of one area changes design constraints of the 
shared area. 

Note: If User selects distributed MP for initial connection type / redundancy then RingMaster will 
select MX from the primary/redundant closet with the least DAP connections. If MXs are not available in 
the primary/redundant closet or if redundant closet is not provided then RingMaster will use MX in the 
mobility domain with least DAP connection. 
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3.4.3 WORKORDER 

• New column will be added in MP table to display serial number of the distributed MP. 

• Wiring closet distance table will not be generated for a distributed MP. 

• For distributed MP we will display "LAN/WAN" text in MX Port column of all the tables. 

• All the above changes need to be updated in both English and German version. 



Mobility Points (MP) 



MP sorted by <}ist»nce from die top-left corner of tn* floor pl*i>. 



Index 


MP Name 


Model 


MX Port (Name:Port) 


MX Port (Name: Port) 


Serial Number 


Coverage Area (302.11a) 


Coverage Area (882.1 tb/g) 


1 


MP- isi- 23 


MP-252 


ran- 104:PO9 


mX4394:P09 




4Sf 


*s<lf 


2 


MP-asf-35 


MP-252 


LAN/WAN 


LAN/WAN 




»sf 




3 


MP-»sf-36 


MP-252 


LAN/WAN 






»sf 




4 


MP-*sf-33 


MP-252 


LAN/WAN 






*sf 




5 


MP-»sf-29 


MP-252 


mx-104:P15 






asf 





3.5 OTHER ENHANCEMENTS 

3.5.1 TREE VIEW 

In the Devices Tree View, DMPs will appear in a separate folder under the Device. This is to visually 
show existence of certain DMP configurations on the MX. It will appear as follows: 
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|fi3Trapeze Networks RingMaster 1.1.0; Plan (MoveVersjon2) • V- 
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3.5.2 CREATE DMP WIZARD 

Unlike "direct-cortnect" MP, DMPs will have a create wizard to insert a DMP in an MX. It will allow 
the user to create the DMP in its basic form. To add/remove redundancy, the user will have to edit that 
DMP. Since RingMaster allows manual configuration of MPs, this create wizard will enable the user to 
create a DMP. However, it is always recommended to the user to use RF Planning tool to create the 
necessary MPs for their deployment. 




Trapeze Networks Confidential 



Page 27 of 45 



Ringmaster 2.0 Functional Specification 



Revision: 0.12 



3.53 EDIT MP WIZARD 

In the current MP wizard, the GUI is restricted to a maximum of 2 port configs. With the introduction 
of DMP configurations, an MP can have more than 2 port configs, if the port type is DMP port. 

The Ul will be modified as follows to allow the user to add, modify, and delete one or more 
Connection information of the MP 




The user will be able to "ADD" two types of connections: 
Direct-connect (Local) 
Distributed 
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The user will be able to "Modify" any connection information. The user can use this feature to move 
the connection information within the same type of connection. For example, if the user edits a "direct- 
connecf connection information, the user will be able to move within any available MX ports. 

When the user attempts to create/modify direct-connect connection information, following UI will be 
shown: 




When the user attempts to create/modify distributed connection information, following UI will be 
shown: 
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In addition to the above functionality, the WIZARD will restrict the following: 

1. An MP cannot have more two "direct-connect" connections. 

2. If an MP has 2 "direct-connect" connections, it cannot have any "distributed" connections. 

3. An MP can have only one "indirect-connect" connection per MX. 

4. Any serial number modified here, will be applied to all "Distributed" connection information. 

5. At least one connection information must be present in order to finish this wizard. The Delete 
action will be disabled if only one connection is remaining. 

3.5.4 CHASSIS WIZARD 

The user will be provided another action button to launch creation of Distributed MPs as shown in the 
following picture: 
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3.5.5 REBOOT DIALOG 



The user will be able to select Distributed MPs for reboot as shown in the following picture: 




The user will be able to view the status of the reboot of a Distributed MP. 

3.5.6 INVENTORY REPORT 

Moibility Point Table will also include any "indirect-connections" to a Mobility Point. 



The count of MP shown per MX will also consider DMP configurations within the MX 



MX(s) 


MP 
Nam 

e 


Mode; 
1 


Serial 
Number 1 


Bootioader Version 


Radi j 
o 1 
Typej 


Radi 
o 2 j 
Type 


Radio 1 MAC 
Address 


Radio 2 MAC 
Address 


mx- 

104: P04 
mx- 

104:P06 
mx- 
104: 
DAP1 


MP04 


MP- 
122 


0321700018 


gA_1.0.0.175jPBt 


B 


A 






mx- 

104:P08^ 


MP08 


MP- 
252 


0321500047! 


QA_1.1.O.67JJ0Q| 


G 1 


A 


00:0e:0b:00:04:d 
3 


00:0e:0b:00:04:d ! 
4 
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3.6 FAULT MANAGEMENT 

The User will be able to see the status of Distributed MPs in RingMaster. The status of MP will be a 
cumulative status of all its redundant configurations. 

In addition to the radio status, the user will be able to see the IP address of the MP that it got assigned 
during its boot process. This will be visible in the Property panel of the MP. If the MP is running an image 
version less than 2.0, this field will have no value. 

3.7 IMPACT ON RF DETECTION 

There will be changes in RP Detection configuration page when user selects MPs to exclude all direct- 
connect and distributed MP will be shown. 

In RF detection results page when user selects known or missing devices both direct-connect and 
distributed MP are considered. 

3.8 NETWORK TOPOLOGY VERIFICATION 

Network Topology Verification provides useful information to the user and can be used for the 
following purposes: 

• Find out information about unconfigured MPs in the network 

• Find out information about mis-configured MPs in the network 

• Find out information about configured MPs that are not reporting any status 

• Find out information about MPs that are physically multi-homed but not so in the 
configuration 

• Find out information about an MP that has booted off an MX that had a lower Bias setting in 
its configuration 



This information can be used by the user to update/correct the configurations in the network Plan. 
Currently, the user has to do it manually. RingMaster will now provide easy actions in the network 
topology window to correct certain kinds of information. They are: 

• Ability to update Redundancy information of MP 

• Ability to update Serial Number of MP 



3.8. 1 VERIFY UNCONFIGURED MPS 

An MP can be connected to the network either with "direct 7 ' or "indirect" connections, even before it is 
configured in the network plan and available on any one MX in the mobility domain. This rule will catch 
such "orphans" and notify the user. 
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3.8.1.1 DIRECT- CONNECT MP 

When an MP is directly connected to MX, it is expected to have a MP configuration record at that 
particular port. Failure to find that record on that port where MP is requesting configuration from, will flag 
this MP as an "orphan" RingMaster will continue to use the existing AP-ANN OUNCE- STATUS to 
deduce this information. 



3.8.1.2 DISTRIBUTED MP 

When an MP is totally distributed, it is considered an "orphan" by the MX that received the 
configuration request, if that MX did not find any other MX in the domain to contain its configuration. It is 
possible that this record can move from one MX to another, if another MX is chosen by MP to request for 
its configuration. RingMaster will use the new DAP-ANNOUNCE-STATUS record to obtain this 
information 




Action Item: (NOS team) to verify the above note 



3.8.1.3 MP WITH ONE DIRECT-CONNECTION AND ONE INDIRECT-CONNECTION 

For An MP that is "mixed" in connections, that is one direct and other indirect; RingMaster will use 
either AP-ANNOUNCE-STATUS or DAP-ANNOUNCE-STATUS to show the "orphan". Either or both 
records will have information about the "orphan". 

3.8.2 VERIFY CONFIGURED MPS NOT REPORTING STATUS 

This rule will catch "configured APs not reporting status" and notify the user. 



3. 8. 2. 1 DIRECT- CONNECT MP 

When an MP is directly connected to MX, it is expected to have a MP configuration record at that 
particular port. Failure to find AP-ANNOUNCE-STATUS record on that port, will flag this MP as an 
"configured AP not reporting status". 



3.8.2.2 DISTRIBUTED MP 

When an MP is totally distributed, it is considered a "Configured MP not reporting status" when there 
is no DAP-ANNOUNCE-STATUS record found for that serial number. 



3.8.2.3 MP WITH ONE DIRECT-CONNECTION AND ONE INDIRECT-CONNECTION 

Failure to find any AP-ANNOUNCE-STATUS record for the direct-connection and DAP- 
ANNOUNCE-STATUS record for that serial number will indicate that this "configured AP is not reporting 

status". 
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3.8.3 VERIFY MIS-CONFIGURED MPS 

This rule will catch "MP model mismatch" and notify the user. It will use the "model" information 
provided in AP-ANNOUNCE-STATUS or DAP-ANNOUNCE-STATUS. 

3.8.4 VERIFY REDUNDANCY CONFIGURATIONS 
This rule will catch one of the following errors: 

1 . MP is directly connected to two MX ports, however, in configuration, they are not redundant 

2. MP is directly connected to two MX ports, however, in configuration, the MP is redundant with 
different port 

3. MP is connected to one MX using "direct-connection", and other MX using "indirect-connection", 
and the MP is not redundant in the configuration 



3.8.5 VERIFY SERIAL NUMBER CONFIGURATION 

This rule will check for serial number configuration of an MP that has a "mixed" set of connections. 
Typically, if MP is totally distributed and the serial number is incorrect, it will be discovered as an 
"orphan". However, if it has one direct-connection, there is a possibility that the MP boots off that MX port 
and it may have a different serial number, in its configuration 

It will be a serial number mis- configuration, if: 

MP is configured to one MX using "direct-connection" and other MX using "indirect-connection" and 
configured with Serial Number "X", but MP with Serial Number "Y" is connected to the above 
configuration. (MP is not an orphan but has a serial number mis-configuration) 

3.9 VERIFICATION RULES 

Following rules will be implemented: 

1 .. Configuration of Indirect-connection on an MP is not supported in MX version below 2.0 

2. Warn the user when coverage area is associated to a remote wiring closet when you have direct 
connected MPs in the coverage area 

3. Generate an error if user tries to deploy a distributed MP without a serial number. 

4. Generate an error if there is more than allowed MP (direct-connected + distributed) for a given 
MX type. 

5. Generate an error if both main and redundant MX is the same for a distributed MP. 

6. Warn the user if distributed MP has more than allowed redundant connections. 

7. Warn the user if distributed MP is created on older version of the box that does not support 
distributed MP. 



Trapeze Networks Confidential 



Page 34 of 45 



Ringmaster 2.0 Functional Specification 



Revision: 0.12 



3.10 CLI MAPPING/DTD CHANGES 

There will be a need to correct the CLI mappings for some commands that will have additional 
attributes or values. 

3.10.1 CLI COMMANDS 

Configuration of Distributed MPs will have a separate set of CLI commands. Actual CLI Commands 
will be provided by Product Management. 

Creation of DAP: 

Set dap <dap number> serial-number <sno> model <model> type <type> 
Modification of DAP: 

All current AP commands will apply to "DAP" with the replacement of keyword "ap" by "dap". As an 
example, 

Set ap 1 radio 1 channel 64 (for AP connected on port 1) 

Set dap 1 radio 1 channel 64 (for dap configured on MX on dap number 1) 

In addition to modify serial number of a dap, the CLI command 

Set dap 1 serial-number <new sno> will be supported. 
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3. 1 0.2 DTD MODEL CHANGES 

For Configuration, following instance model will be used to distinguish between direct-connect AP 
and Distributed AP. 



Rad)o-profil»-table 



3ST 



PHYSINFO 



OP-CHASSIS 



DP-DMP-TABLE 



DP-PHYS-MODULES 



z 



DP-PHYS-MODULLE 



DP-PHYS-PORT 



DP-PHYS-100BT 



IE 



AP-TABLE 



is: 



Wink 
sticky 

boot-download-enabled 



seriatnum 



type 

bias 

blink 
-sticky 
-boot-download- enabled 



RADIO-TABLE 
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I 











DP-DAP-ANNOUNCE TABLE 











DP-DAP-ANNOUNCE-STATUS 


-,or)3l numbBr 
-status : <unspi 

-bool-ip 

-boot-bias 

-manuf-ld 

• bootload*r-rev 


>cifl»d> = ORPHANED J MISMATCH | OK 





A DAP has a status of "orphaned", if there is no config record for that serial number 

A DAP has a status of "mismatch", if the model does not match but sno matches. 

A DAP has a status of "OK", if the MP has booted off this MX and therefore, will have non-null 
values in boot-ip and boot-bias 



3.11 STATISTICS 

The Statistics module will be enhanced to be able to handle Distributed MPs 

3.12 IMPACT OF MX VERSIONING 

Certain CLI commands or attribute value pairs will not be available for certain versions of MX 
software. This will impact various planning operations. 
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4 POLICY MANAGEMENT 



4.1 CURRENT DESIGN & ISSUES 

In 1.x RingMaster the Mobility Domain Policy object is effectively an MX-20 device. This means that 
as new devices are created from scratch, the system would automatically clone the MX-20 policy as the 
basis for a new device. 



4.1.1 SUPPORT FOR MULTIPLE DEVICE TYPES & VERSIONS 

As we introduce more device types into the supported device set in RingMaster the current scheme 
does not work. The policy system also does not take into account software revisions. 



4. 1 .2 POLICY CRITERIA 

In 1 .x RingMaster only allows a single policy per mobility domain. This is not flexible, as the user 
may want to pick and choose devices across mobility domains, or a subset of devices within a mobility 
domain, to be policy controlled. 

For example, a user may want to define a AAA policy that spans all devices regardless of mobility 
domain membership. 

Also, moving forward a user may want to define a policy that is limited to certain device types or 
software versions. 



4. 1 .3 CHOOSING WHAT TO APPLY 

Currently the entire policy is always applied to the device to produce a diff-set that is shown as CLI 
commands. Then the user can select individual CLI commands to Apply to the device. 

This can be dangerous also gets annoying to see unrelated changes each time the policy is applied and 
to have to deselect commands that are not needed. For example if the user wants to only use the policy for 
AAA data, they have to always deselect clearing of unrelated data like MOTD, default routes, or have to 
update the policy to contain that data. 

4.2 PROPOSED CHANGES 

1) The policy object no longer exists per mobility domain. We define a new policy database per plan. 
The database starts out empty, and the user can add/delete policies to the database at any point. 

2) Policies contain set of criteria which determines whether they should be selected for a device. 
Initially the scope can be the device type and software version. 

3) When a device is created or uploaded, policies with the criteria that matches the device will be 
selected for it. The user can fine rune thus or accept all matching policies. For created devices, data 
from all selected policies will be applied; for uploaded devices, an association will be formed but 
the data will not be applied till the policy manager is invoked. 

4) Devices and policies can be associated or disassociated at any point. The user can select a device 
and modify its policy associations. The user can also delete/add polices, or modify its criteria. 
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5) When a policy is created one or more of the following functional areas can be chosen. A 
functional area is any sub-tree of data in the containment hierarchy. Here is a starting list: 

a. Management services 

b. VLANs 

c. STP Properties 

d. ACLs 

e. IP Services 

f. Radio Profiles 

g. Load Sharing 

h. AAA 

i. Radius 

ii. Local User Database 

iii. Admin Access Rules 



iv. Network Access Rules 
i. Mobility Profiles 




lfe§The policy manager function will allow the selection of one or more policies to be applied. The 



8) The Device -> Policy merge will be deprecated. Instead the user will be given a command/action 
to simply converting device data into policies. For example the user can select a VLAN in a device 
and select a menu option "Make Policy". This will launch a wizard that allows the user to create a 
new policy with that data, or conceivably Apply that data to an existing policy. Underneath this is 
the same as doing a "cut & paste" operation from a device to a policy. 



4.3 QUESTIONS & ISSUES 

• The design and level of support for versioning will impact this and other features. Some of the 
questions that come up are: 

o If the user does not select any device version restriction the UI will operate in the latest 
version. How does this work for device types. For example the VLAN wizard for an MX-6 
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device will show a different number of available ports than a VLAN wizard foV a MX-20. 
When we configure a VLAN in the policy, the type has to be known to show the available 
ports. Same for mobility profiles, and other objects that depend on the physical aspects of the 
device. 

o If a policy is applied to a device that is off the wrong type, the user should be somehow 
shown a failure. For example, if we create a VLAN policy and add 20 VLAN members to it 
and Apply it to an MX-6 device, this should be flagged as an error. 

• Can we somehow show a status of pending policy changes? 

• The policy manager can have a drop-down list of policies and show affected devices. But this may be 
tedious so how can we intuitively allow the user to select multiple policies at once? We could show the 
changes as demarked groups that can be selected or unselected. 

• Performance improvements? 

4.4 CREATE POLICY 

1. When a new plan is created, it contains an empty Policy DB. The user can add or delete 
polices to the policy database. 



Mobility Domains 



E& - : Policy DB 

AAA Policy 

j VLAN Policy 

Bob's Policy 

ffi Default 



Sites 



2. The Create Policy wizard consists of 3 steps: 

a. Policy Setup: here the user can name the policy and define its criteria. 

b. Device Selection: all devices that match the defined criteria are eligible to be 
selected. By default none are, and the user can add in the appropriate devices. 

c. Policy Data Setup: the user can select what data is to be in the policy and also launch 
nested wizards to configure that data. 
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Create Policy Wizard " ■■■■■ ./• 




Create Policy Wizard. 
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Creat e Policy Wizard 




4.5 MODIFY POLICY 



The user can select a policy in the organizer panel and launch a modify wizard for it. This will have the 
same flow as the Create Wizard. The user can also select a previously enabled configuration area under 
the policy and directly launch a modify wizard for that area. 



Mobility Domains 



T Policy DB 

95--T Bob's Policy 

j- Management Services 

| VLANs 

Spanning Tree Properties 

IP Services 



The user can edit the policy name and/or criteria. However, if the policy has associated devices that 
will not match the updated criteria the user will be prompted to de-associate those devices first. 
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4.6 DELETE POLICIES 

Policies can be deleted, like any other model object. 

4.7 ASSOCIATE DEVICES & POLICIES 

When creating a Policy it can be associated to devices. Also while creating, uploading, and/or 
modifying a device the user can fine-tune the policy assignments for that device. 

A "Policy Selection" page will be available in the Create/Modify/Upload device wizards. In this page 
the user can add or delete policy associations for the device. The user can also order the policies for the 
device. The ordering is only important if multiple policies have overlapping data. 




4.8 APPLY POLICIES 

Policies are applied to devices using the Policy Manager. 

1 . User selects a single policy or all policies to be applied. 

2. The list of devices with pending changes for the selected policies is calculated and displayed. 

3. The user can click on an individual device and see what the result of Applying the policy is as CLI 
commands. 

4. The user can un-select a particular set of changes (grouped by the applied policy.) 

5. The user then clicks Apply. The list of changed devices is re-calculated and displayed. 
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Policy Manager 




4.9 CREATE POLICIES FROM DEVICE DATA 

A user may want to make a device's configuration data into a policy. This can be done by creating a 
policy and the doing a copy-n-paste of the data. It would be nice to provide a one step operation to do that. 

1 . User selects a device configuration element. If this is a configuration element that is policy 
enabled (i.e. not a port/MP, etc.) and is a policy sub-tree the user can select a menu option to 
make a policy out of the data. 

2. A wizard will prompt the user to as if they want a new policy, or to add the data to an existing 
policy. The wizard will guide the user through the remaining steps to setup the policy (similar 
to create/modify policy.) 

4.1 0 READING OLD PLANS - BACKWARD COMPATIBILITY 

The release which implements this feature will need to support the reading &conversion of network 
plans that have the old policy hierarchy. 

The conversion will be done as follows: 

1. For each mobility domain in the old plan, a policy will be created in the new plan, under the 
policy database, with the name: "<Modo Name> Policy". 

2. The new policy will have associations with all members of the mobility domain in was 
created from. 

This conversion will most likely be implemented in an XSLT stylesheet and will be plugged in to the 
overall version conversion framework (see section on Versioning.) 

4.11 IMPROVE PERFORMANCE 
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There have been complaints on the performance of (or lack thereof) the Policy dialog, and the 
underlying CLI mappings. Here are some things that can be done: 

1 . Profile to/from CLI code to identify any bottlenecks. 

2. Scrub all CLI mappings to optimize how XPATH is used. 

3. Allow to-CLl output to be streamed rather than wait for all commands to be generated. 

4. See if XML->CS->CLI->XML->MODEL algorithm for the policy manager can be simplified. We 
can still use the CLI as a display but can internally Apply the XML which would avoid a CLI- 
>XML conversion. 

4.12 DELIVERABLES & ESITMATES 

Here are some rough estimates (development & test) for the deliverables: 

1. Model changes - Create/modify/delete policies: 4 days 

2. Associate devices & policies: 2 days 

3. Apply policies: 4 days 

4. Multiple version & device type support: 4 days 

5. Reading old plans - backward compatibility: 3 days (2 days for f/w +. 1 day for policy) 

6. Create policies from device data: 2 days 

7. Performance Improvement: 2 days 



4.13 NOTES ON IMPLEMENTATION 

1) There are various ways we could implement the policy rules. One way would be to actual create a 
new policy class that contains the criteria part: 

• a list (would be individual Booleans actually) of device types (out of the descriptor map) 

• a list (again would be individual Booleans) of software revisions. 

The action/data part would be stored as an XML fragment of configuration. This means that the XML 
fragment(s) would not be completely parented (i.e. belonging to a device). For the AAA example, the root 
object would be the AAA class and would be owned by the policy object itself. Maybe a one-one tightly 
coupled relation would work so that if we were to delete the policy rule it would delete the configuration 
fragment. There would also be various other modifications to the system to allow such objects to be edited 
reusing the same pages/wizards without requiring a complete device hierarchy to support the configuration 
element. 



2) In 1.0 each object or device that is controlled by a policy has a pointer to the policy object. We 
would have to make sure that after pushing a policy to a device that the particular object itself is tied to the 
policy rather than assuming the whole device is controlled by a single domain policy. 
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